Hi Keith,
Yes, T=1 was calling createScanner, and yes, my current code does create
single scanner per thread, but I already have new code does use
BatchScanner.
For T=4, it's another thread, but I believe it was spawned from thread
0x1f46, there are many of this stack, and I just noticed few of them have
this stack:
"pool-3-thread-1277" #7656 prio=5 os_prio=0 tid=0x00007fee9408e000
nid=0x2033 waiting for monitor entry [0x00007fef9f0f1000]
java.lang.Thread.State: BLOCKED (on object monitor)
at
org.apache.accumulo.core.client.impl.TabletLocator.getLocator(TabletLocator.java:101)
- waiting to lock <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)
...
That 'BLOCKED' state seems suspicious to me.
For T=5, the high level thread was calling scanner iterator's hasNext()
Do you know why reading via this connector would take > 8s, while on new
connector (in same process), the read would mostly only take < 0.1s (see
that huge difference)?
Thanks,
Z
--
View this message in context:
http://apache-accumulo.1065345.n5.nabble.com/cached-connector-tp16202p16262.html
Sent from the Developers mailing list archive at Nabble.com.
