[
https://issues.apache.org/jira/browse/HBASE-10205?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13853615#comment-13853615
]
Arjen Roodselaar commented on HBASE-10205:
------------------------------------------
Fair point, I should have thought about this a bit harder. Since we want
multiple writer threads to deal with the possible fsync'ing to a device but the
off heap implementation will probably suffer from contention on the
BucketAllocator, does it make sense to just assume the BucketAllocator to not
be thread safe, and instead have an AllocatorThread pulling entries from a
LinkedTransferQueue, assign the bucket and offset (and perform freeSpace if
necessary) and hand them over to one of the writer threads?
> ConcurrentModificationException in BucketAllocator
> --------------------------------------------------
>
> Key: HBASE-10205
> URL: https://issues.apache.org/jira/browse/HBASE-10205
> Project: HBase
> Issue Type: Bug
> Components: regionserver
> Affects Versions: 0.89-fb
> Reporter: Arjen Roodselaar
> Assignee: Arjen Roodselaar
> Priority: Minor
> Fix For: 0.89-fb, 0.99.0
>
> Attachments: hbase-10205-trunk.patch
>
>
> The BucketCache WriterThread calls BucketCache.freeSpace() upon draining the
> RAM queue containing entries to be cached. freeSpace() in turn calls
> BucketSizeInfo.statistics() through BucketAllocator.getIndexStatistics(),
> which iterates over 'bucketList'. At the same time another WriterThread might
> call BucketAllocator.allocateBlock(), which may call
> BucketSizeInfo.allocateBlock(), add a bucket to 'bucketList' and consequently
> cause a ConcurrentModificationException. Calls to
> BucketAllocator.allocateBlock() are synchronized, but calls to
> BucketAllocator.getIndexStatistics() are not, which allows this race to occur.
--
This message was sent by Atlassian JIRA
(v6.1.4#6159)
