[
https://issues.apache.org/jira/browse/HBASE-2669?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12893201#action_12893201
]
Héctor Izquierdo commented on HBASE-2669:
-----------------------------------------
An ugly workaround:
private Thread getEvilHTableShutdownHook() throws Exception {
Class clazz = Class.forName("java.lang.ApplicationShutdownHooks");
Field[] fields = clazz.getDeclaredFields();
for (Field field : fields) {
if (field.getType() == IdentityHashMap.class) {
field.setAccessible(true);
IdentityHashMap<Thread, Thread> hooks =
(IdentityHashMap<Thread, Thread>) field.get(null);
for (Map.Entry<Thread, Thread> entries : hooks.entrySet()) {
System.out.println(entries.getKey().getName());
if
(entries.getValue().getName().equals("HCM.shutdownHook")) {
return entries.getValue();
}
}
}
}
return null;
}
> 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
>
>
> 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.
