[
https://issues.apache.org/jira/browse/ACCUMULO-3835?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15060680#comment-15060680
]
Christopher Tubbs commented on ACCUMULO-3835:
---------------------------------------------
Do we want to backport this bugfix to 1.6.5 or 1.7.1, since it was originally
reported against 1.6.2?
> TabletServerBatchReaderIterator concurrency contention on early close()
> -----------------------------------------------------------------------
>
> Key: ACCUMULO-3835
> URL: https://issues.apache.org/jira/browse/ACCUMULO-3835
> Project: Accumulo
> Issue Type: Bug
> Components: client
> Affects Versions: 1.6.2
> Reporter: marco polo
> Assignee: Eric Newton
> Fix For: 1.8.0
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> When running many batch scanners in a JVM, we see a significant amount of
> cache invalidation within the JVM when we prematurely close the batch
> scanner. When we prematurely close the batch scanner ( and threads within it
> are running an interrupt is sent to those threads, causing them to add the
> extents to the failures map and invalidate the cache. This causes lock
> contention on the write lock for the TabletLocatorImpl.
> The lock contention hinders performance in a highly parallel client that does
> not need to invalid the cache as a result of being stopped.
> As a positive test to ensure this was my problem I added a conditional check
> to the IOException handler in the run method of
> TabletServerBatchReaderIterator. The conditional checked whether the query
> thread pool was shut down. If it was not, we would invalidate the cache as we
> can assume the reason likely wasn't interruption. If it was shut down, we
> would not invalide the cache. This reduced lock contention dramatically and
> reduced runtime. This should cause no harm as any other failure would cause
> cache invalidation through some other route.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
