[ https://issues.apache.org/jira/browse/ACCUMULO-2362?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13905996#comment-13905996 ]
Josh Elser commented on ACCUMULO-2362: -------------------------------------- Thanks for the advice, [~kturner]. I think most of the time, the contention should only arise when creating the objects (as opposed to reading data) as we don't re-fetch things like the tableID, but this would be a good factor to include (creating the Scanner as opposed to creating and reading data with a Scanner). > Reduce blocking in client API (Tables) > -------------------------------------- > > Key: ACCUMULO-2362 > URL: https://issues.apache.org/jira/browse/ACCUMULO-2362 > Project: Accumulo > Issue Type: New Feature > Components: client > Affects Versions: 1.4.4, 1.5.0 > Reporter: Josh Elser > Fix For: 1.7.0 > > > Presently, the {{Tables}} class contains a static map of instance to ZooCache > that *many* of the classes in the client API use. The problem with this is > that many of the methods on ZooCache ultimately are synchronized. When > multiple threads using Connectors, TableOperations, Scanners/BatchScanners, > and BatchWriters against the same Accumulo instance, you currently have a > massive synchronization problem. > We should give some thought to heavy, concurrent access to Accumulo client > API calls within the same JVM. Consideration should also be given to the > consistency of wrapping zookeeper with a cache like is presently done. -- This message was sent by Atlassian JIRA (v6.1.5#6160)