Also, I forgot this part before:
The ZooCache instance that's used *typically* comes from the Instance
object that your Connector was created from. In other words, if you
create multiple Instances (ZooKeeperInstance, usually), you can get
multiple ZooCaches which means that concurrent calls to methods off of
those objects should not block one another (createScanner off of
connector1 from instance1 should not block createScanner off of
connector2 from instance2).
That should be something quick you can play with if you so desire.
On 2/12/14, 9:57 AM, Josh Elser wrote:
Yep, you'll likely also block on BatchScanner, anything in
TableOperations, and a host of other things.
For scanners, there's likely a standing recommendation to amortize the
use of those objects (if you want to look up 5 range, don't make 5
scanners).
Creating a cache per member in the work would likely require some kind
of paxos implementation to provide consistency which is highly undesirable.
One thing I'm curious about is the impact of removing ZooCache
altogether from things like the client api and see what happens. I don't
have a good way to measure that impact off the top of my head though.
Anyways, is this causing you problems in your usage of the api? Could
you elaborate a bit more on the specifics?
On Feb 12, 2014 4:48 AM, "Ariel Valentin" <[email protected]
<mailto:[email protected]>> wrote:
I have run into a problem related to ACCUMULO-1833, which appears to
have addressed the issue for MutliTableBatchWriter; however I am
seeing this issue on the scanner side also:
394750-"http-/192.168.220.196:8080-35" daemon prio=10
tid=0x00007f3108038000 nid=0x538a waiting for monitor entry
[0x00007f31287d1000]
394878: java.lang.Thread.State: BLOCKED (on object monitor)
394933- at
org.apache.accumulo.fate.zookeeper.ZooCache.getInstance(ZooCache.java:301)
395012- - waiting to lock <0x00000000fa64f5b8> (a java.lang.Class
for org.apache.accumulo.fate.zookeeper.ZooCache)
395120- at
org.apache.accumulo.core.client.impl.Tables.getZooCache(Tables.java:40)
395196- at
org.apache.accumulo.core.client.impl.Tables.getMap(Tables.java:44)
395267- at
org.apache.accumulo.core.client.impl.Tables.getNameToIdMap(Tables.java:78)
395346- at
org.apache.accumulo.core.client.impl.Tables.getTableId(Tables.java:64)
395421- at
org.apache.accumulo.core.client.impl.ConnectorImpl.getTableId(ConnectorImpl.java:75)
395510- at
org.apache.accumulo.core.client.impl.ConnectorImpl.createScanner(ConnectorImpl.java:137)
I have not spent enough time reasoning about the code to understand
all of the nuances but I am interested in knowing if there are any
mitigating strategies for dealing with this thread contention e.g.
would creating a cache entry for each member of the Zookeeper
ensemble help relieve the strain? use multiple classloaders? or is
my only option to spawn multiple JVMs?
Thanks,
Ariel Valentin
e-mail: [email protected] <mailto:[email protected]>
website: http://blog.arielvalentin.com
skype: ariel.s.valentin
twitter: arielvalentin
linkedin: http://www.linkedin.com/profile/view?id=8996534
---------------------------------------
*simplicity *communication
*feedback *courage *respect
