[ https://issues.apache.org/jira/browse/ACCUMULO-1755?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15163437#comment-15163437 ]
Dave Marion commented on ACCUMULO-1755: --------------------------------------- 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)