[ https://issues.apache.org/jira/browse/ACCUMULO-3835?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Eric Newton updated ACCUMULO-3835: ---------------------------------- Fix Version/s: 1.8.0 > 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 > > > 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)