accumulo-notifications mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Keith Turner (JIRA)" <>
Subject [jira] [Commented] (ACCUMULO-2362) Reduce blocking in client API (Tables)
Date Wed, 19 Feb 2014 18:10:19 GMT


Keith Turner commented on ACCUMULO-2362:

Could write a fixed amount of data, vary the number of threads, and plot
the aggregate write rates.   For example write 10 megs of random key values
with 1,2,4,8,16 threads from a single process.  Also read a fixed amount of
data with varying number of threads and plot the aggregate read rates.
Would also need to record the min and max time it took all of the threads
to complete.

I am very curious what these plots would look like.  Would like to see this
test run on machines w/ varying number of cores and no local tservers. Also
the test could use disjoint or overlapping ranges.

> Reduce blocking in client API (Tables)
> --------------------------------------
>                 Key: ACCUMULO-2362
>                 URL:
>             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

View raw message