Of course I did. Using CleanUp.shutdownNow(); works perfectly from
inside the "mvn exec:java" command. Excellent.

On Sun, Nov 30, 2014 at 6:54 PM, Josh Elser <josh.el...@gmail.com> wrote:
> David Medinets wrote:
>>
>> I experimented a bit more. In the waitForZooKeeperClientThreads
>> method, I added a "thread.interrupt" call inside the "while
>> (thread.isAlive())" loop. It seems like the thread is interrupted
>> after a few seconds, but then is reconnected. Darn that resiliency!
>> I've watched it reconnect four times before I killed the process. Can
>> I reset the retry number somehow? Am I too far down the rabbit hole?
>
>
> You shouldn't have to interrupt the ZK threads (I'm not sure what it's doing
> underneath the hood when you do so). As the comment in that method says,
> ZooKeeper.close() is non-blocking, so that loop will finish gracefully
> (given ZooKeeper.close() is performing how we expect it to).
>
>
>> java.lang.InterruptedException: sleep interrupted
>>      at java.lang.Thread.sleep(Native Method)
>>      at
>> org.apache.zookeeper.ClientCnxn$SendThread.startConnect(ClientCnxn.java:1045)
>>      at
>> org.apache.zookeeper.ClientCnxn$SendThread.run(ClientCnxn.java:1101)
>> 2014-11-30 09:29:32,596 INFO
>> [com.codebits.jodoc.WriteAndReadDriver.main(localhost:20000)]
>> zookeeper.ClientCnxn (ClientCnxn.java:startConnect(1058)) - Opening
>> socket connection to server localhost/127.0.0.1:20000
>> 2014-11-30 09:29:32,597 INFO
>> [com.codebits.jodoc.WriteAndReadDriver.main(localhost:20000)]
>> zookeeper.ClientCnxn (ClientCnxn.java:primeConnection(947)) - Socket
>> connection established to localhost/127.0.0.1:20000, initiating
>> session
>> 2014-11-30 09:29:32,599 INFO
>> [com.codebits.jodoc.WriteAndReadDriver.main(localhost:20000)]
>> zookeeper.ClientCnxn (ClientCnxn.java:readConnectResult(736)) -
>> Session establishment complete on server localhost/127.0.0.1:20000,
>> sessionid = 0x1
>>
>>
>> On Sun, Nov 30, 2014 at 9:10 AM, David Medinets
>> <david.medin...@gmail.com>  wrote:
>>>
>>> Right again. I changed the package name to "jaredwinick" and the
>>> "sealing violation" issue was resolved. But the JIRA ticket comments
>>> were correct about the code's being brittle. It has a String literal
>>> that refers to "org.apache.accumulo.core.zookeeper.ZooSession"which
>>> does not exist in Accumulo v1.6.1.
>
>
> I'm sure Jared is pleased with your alternative package name.
>
> Did you copy/paste the code Jared had on his Github rather than using the
> variant we have in the codebase (org.apache.accumulo.core.util.CleanUp)?

Reply via email to