Hi Keith,
This is the thread that holding the lock on 0x000000068032c130:
"pool-3-thread-1273" #7652 prio=5 os_prio=0 tid=0x00007fee94088800
nid=0x202f waiting for monitor entry [0x00007fef9f4f5000]
java.lang.Thread.State: BLOCKED (on object monitor)
at
org.apache.accumulo.core.client.impl.TabletLocator.getLocator(TabletLocator.java:101)
- locked <0x000000068032c130> (a java.lang.Class for
org.apache.accumulo.core.client.impl.TabletLocator)
at
org.apache.accumulo.core.client.impl.ThriftScanner.scan(ThriftScanner.java:228)
at
org.apache.accumulo.core.client.impl.ScannerIterator$Reader.run(ScannerIterator.java:84)
at
org.apache.accumulo.core.client.impl.ScannerIterator.hasNext(ScannerIterator.java:177)
...
Does this give any clue to you?
I think what you mentioned does make sense, something could change on
zookeepers. In that case, I wish the client API is able to detect that, and
remove the bad zk (or perhaps refresh the cache)
Ok, for now I am thinking to recycle the process.
I am thinking to change the code to not cache the connector, as creating it
is not expensive (as Josh mentioned), that should solve this problem for
sure.
Thanks,
Z
--
View this message in context:
http://apache-accumulo.1065345.n5.nabble.com/cached-connector-tp16202p16267.html
Sent from the Developers mailing list archive at Nabble.com.
