You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@zookeeper.apache.org by "wu wen (JIRA)" <ji...@apache.org> on 2016/11/08 03:37:58 UTC
[jira] [Updated] (ZOOKEEPER-1816) ClientCnxn.close() should block
until threads have died
[ https://issues.apache.org/jira/browse/ZOOKEEPER-1816?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
wu wen updated ZOOKEEPER-1816:
------------------------------
Attachment: ZOOKEEPER-1816.patch
> ClientCnxn.close() should block until threads have died
> -------------------------------------------------------
>
> Key: ZOOKEEPER-1816
> URL: https://issues.apache.org/jira/browse/ZOOKEEPER-1816
> Project: ZooKeeper
> Issue Type: Bug
> Components: java client
> Affects Versions: 3.3.6, 3.4.5
> Reporter: Jared Winick
> Priority: Minor
> Attachments: ZOOKEEPER-1816.patch
>
>
> In the testing of ACCUMULO-1379 and ACCUMULO-1858 it was seen that the non-blocking behavior of ClientCnxn.close(), and therefore ZooKeeper.close(), can cause a race condition when undeploying an application running in a Java container such as JBoss or Tomcat. As the close() method returns without joining on the sendThread and eventThread, those threads continue to execute/cleanup while the container is cleaning up the application's resources. If the container has unloaded classes by the time this code runs
> {code}
> ZooTrace.logTraceMessage(LOG, ZooTrace.getTextTraceLevel(), "SendThread exitedloop.");
> {code}
> A "java.lang.NoClassDefFoundError: org/apache/zookeeper/server/ZooTrace" can be seen.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)