[
https://issues.apache.org/jira/browse/ACCUMULO-1755?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15178398#comment-15178398
]
Dave Marion commented on ACCUMULO-1755:
---------------------------------------
bq. The previous implementation blocked all client threads from calling
BatchWriter.addMutation(), meaning the clients could not do any work. In the
new implementation the clients will be able to continue to do work, adding
mutations, and even binning them in their own thread if necessary, before
blocking.
My statement from above is incorrect. We didn't remove the synchronization from
TabletServerBatchWriter.addMutation. We only made it such that the binning is
done either in a background thread or the current thread.
> 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
> Assignee: Dave Marion
> Fix For: 1.6.6, 1.7.2, 1.8.0
>
> Attachments: ACCUMULO-1755.patch
>
> Time Spent: 2h
> Remaining Estimate: 0h
>
> 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)
