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

ASF GitHub Bot commented on ACCUMULO-1755:
------------------------------------------

Github user keith-turner commented on the pull request:

    https://github.com/apache/accumulo/pull/75#issuecomment-189526782
  
    > I added a catch clause to startProcessing to catch the 
RejectedExecutionException that can be thrown. Were you thinking of something 
else?
    
    What you did is needed, but I was thinking of something else.   If the call 
to `addMutations()` in the Runnable throws an unexpected exception, nothing 
will be done about that exception. The batch writer should transition to an 
error state.  Thinking need to do something like the following.
    
    ```java
    void queueMutations(final MutationSet mutationsToSend) {
          queueThreadPool.submit(new Runnable() {
            public void run() {
              try{
                addMutations(mutationsToSend);
              } catch (Exception e){
                updateUnknownErrors(e);
              }
            }
          });
        }
    
    ```


> 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.8.0
>
>          Time Spent: 0.5h
>  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)

Reply via email to