accumulo-notifications mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Dave Marion (JIRA)" <j...@apache.org>
Subject [jira] [Comment Edited] (ACCUMULO-1755) BatchWriter blocks all addMutation calls while binning mutations
Date Wed, 24 Feb 2016 18:08:18 GMT

    [ https://issues.apache.org/jira/browse/ACCUMULO-1755?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15163437#comment-15163437
] 

Dave Marion edited comment on ACCUMULO-1755 at 2/24/16 6:07 PM:
----------------------------------------------------------------

We could solve this by:

1. Making MutationSet.mutations a ConcurrentHashMap
2. Making MutationSet.memoryUsed an AtomicLong
3. Not synchronizing on access to TabletServerBatchWriter.mutations
4. Changing TabletServerBatchWriter.mutations to an AtomicReference so that it is safe to
swap it out in startProcessing()
5. In startProcessing(), swap in a new MutationSet then add the mutations from the previous
MutationSet to the writer.


was (Author: dlmarion):
We could solve this by:

1. Making MutationSet.mutations a ConcurrentHashMap
2. Not synchronizing on access to TabletServerBatchWriter.mutations
3. Changing TabletServerBatchWriter.mutations to an AtomicReference so that it is safe to
swap it out in startProcessing()
4. In startProcessing(), swap in a new MutationSet then add the mutations from the previous
MutationSet to the writer.

> BatchWriter blocks all addMutation calls while binning mutations
> ----------------------------------------------------------------
>
>                 Key: ACCUMULO-1755
>                 URL: https://issues.apache.org/jira/browse/ACCUMULO-1755
>             Project: Accumulo
>          Issue Type: Improvement
>          Components: client
>            Reporter: Adam Fuchs
>
> Through code inspection, we found that the BatchWriter bins mutations inside of a synchronized
block that covers calls to addMutation. Binning potentially involves lookups of tablet metadata
and processes a fair amount of information. We will get better parallelism if we can either
unlock the lock while binning, dedicate another thread to do the binning, or use one of the
send threads to do the binning.
> This has not been verified empirically yet, so there is not yet any profiling info to
indicate the level of improvement that we should expect. Profiling and repeatable demonstration
of this performance bottleneck should be the first step on this ticket.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

Mime
View raw message