[
https://issues.apache.org/jira/browse/HBASE-17434?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15811603#comment-15811603
]
Ted Yu commented on HBASE-17434:
--------------------------------
I feel that the proposed change shouldn't be taken out of context (i.e. prior
discussion on HBASE-17379).
Without HBASE-17081 in play, we wouldn't know for sure that the proposed change
would fix HBASE-17379.
I am open to alternative solution for HBASE-17379 but the current patch on this
JIRA is not clean:
1. As I commented above, it would be better to implement copy on write in
building block methods (add, etc). This would make future change / addition of
methods which alter pipeline less prone to error.
As shown in later versions of patches on HBASE-17379, making copy in building
block methods (add, etc) doesn't entail second lock. There is no duplicate
locking.
2. It is not standard practice to have a volatile field (for reads) of the same
type of the field which is modifiable.
> 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, HBASE-17434-V02.patch,
> HBASE-17434-V03.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)
