hbase-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Benoit Sigoure (JIRA)" <j...@apache.org>
Subject [jira] Commented: (HBASE-2669) HCM.shutdownHook causes data loss with hbase.client.write.buffer != 0
Date Mon, 02 Aug 2010 21:45:16 GMT

    [ https://issues.apache.org/jira/browse/HBASE-2669?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12894723#action_12894723
] 

Benoit Sigoure commented on HBASE-2669:
---------------------------------------

I'm OK with your patch stack, thanks for putting it together.

Minor stylistic nit: it's not clear to me why the import of {{MetaScanner.MetaScannerVisitor}}
has moved around in {{HMaster.java}}, lines are now out of order.  Plus, I don't think {{HMaster.java}}
should be changed as part of this issue, as this issue has nothing to do with the master.

> HCM.shutdownHook causes data loss with hbase.client.write.buffer != 0
> ---------------------------------------------------------------------
>
>                 Key: HBASE-2669
>                 URL: https://issues.apache.org/jira/browse/HBASE-2669
>             Project: HBase
>          Issue Type: Bug
>          Components: client
>            Reporter: Benoit Sigoure
>            Assignee: Benoit Sigoure
>            Priority: Critical
>             Fix For: 0.90.0
>
>         Attachments: 2669.txt
>
>
> In my application I set {{hbase.client.write.buffer}} to a reasonably small value (roughly
64 edits) in order to try to batch a few {{Put}} together before talking to HBase.  When my
application does a graceful shutdown, I call {{HTable#flushCommits}} in order to flush any
pending change to HBase.  I want to do the same thing when I get a {{SIGTERM}} by using {{Runtime#addShutdownHook}}
but this is impossible since {{HConnectionManager}} already registers a shutdown hook that
invokes {{HConnectionManager#deleteAllConnections}}.  This static method closes all the connections
to HBase and then all connections to ZooKeeper.  Because all shutdown hooks run in parallel,
my hook will attempt to flush edits while connections are getting closed.
> There is no way to guarantee the order in which the hooks will execute, so I propose
that we remove the hook in the HCM altogether and provide some user-visible API they call
in their own hook after they're done flushing their stuff, if they really want to do a graceful
shutdown.  I expect that a lot of users won't use a hook though, otherwise this issue would
have cropped up already.  For those users, connections won't get "gracefully" terminated,
but I don't think that would be a problem since the underlying TCP socket will get closed
by the OS anyway, so things like ZooKeeper and such should realize that the connection has
been terminated and assume the client is gone, and do the necessary clean-up on their side.
> An alternate fix would be to leave the hook in place by default but keep a reference
to it and add a user-visible API to be able to un-register the hook.  I find this ugly.
> Thoughts?

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


Mime
View raw message