[
https://issues.apache.org/jira/browse/HBASE-17434?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15808895#comment-15808895
]
Manjunath Anand edited comment on HBASE-17434 at 1/8/17 7:11 AM:
-----------------------------------------------------------------
Hi [~eshcar] , I went through this patch and the patch submitted for
HBASE-17081 and felt that using ReentrantReadWriteLock would be more advisable
than synchronized blocks due to below 2 reasons:-
1) Allows readers to concurrently access the pipeline and also allows for fine
grain read and write locks where required
2) Also allows to lock on something other than the pipeline. This makes more
meaning when you compare the drain method implemented in the HBASE-17081 patch
(which has O(N) complexity) versus what I present below (which has O(1)
complexity) using the new locking mechanism:-
{code}
public List<ImmutableSegment> drain() {
List<ImmutableSegment> result = null;
lock.writeLock().lock();
try {
version++;
result = this.pipeline;
this.pipeline = new LinkedList<>();
this.readOnlyCopy = new LinkedList<>();
} finally {
lock.writeLock().unlock();
}
return result;
}
{code}
was (Author: manju_hadoop):
Hi [~eshcar] , I went through this patch and the patch submitted for
HBASE-17081 and felt that using ReentrantReadWriteLock would be more advisable
than synchronized blocks due to below 2 reasons:-
1) Allows readers to concurrently access the pipeline and also allows for fine
grain read and write locks where required
2) Also allows to lock on something other than the pipeline. This makes more
meaning when you compare the drain method implemented in the HBASE-17081 patch
(which has O(n) complexity) versus what I present below (which has O(1)
complexity) using the new locking mechanism:-
{code}
public List<ImmutableSegment> drain() {
List<ImmutableSegment> result = null;
lock.writeLock().lock();
try {
version++;
result = this.pipeline;
this.pipeline = new LinkedList<>();
this.readOnlyCopy = new LinkedList<>();
} finally {
lock.writeLock().unlock();
}
return result;
}
{code}
> New Synchronization Scheme for Compaction Pipeline
> --------------------------------------------------
>
> Key: HBASE-17434
> URL: https://issues.apache.org/jira/browse/HBASE-17434
> Project: HBase
> Issue Type: Bug
> Reporter: Eshcar Hillel
> Assignee: Eshcar Hillel
> Attachments: HBASE-17434-V01.patch
>
>
> A new copyOnWrite synchronization scheme is introduced for the compaction
> pipeline.
> The new scheme is better since it removes the lock from getSegments() which
> is invoked in every get and scan operation, and it reduces the number of
> LinkedList objects that are created at runtime, thus can reduce GC (not by
> much, but still...).
> In addition, it fixes the method getTailSize() in compaction pipeline. This
> method creates a MemstoreSize object which comprises the data size and the
> overhead size of the segment and needs to be atomic.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
