[
https://issues.apache.org/jira/browse/HBASE-7725?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13579000#comment-13579000
]
Jesse Yates commented on HBASE-7725:
------------------------------------
{quote}
I don't think I understand why we have to make attributes visible to HBase code.
For example, when we call this:
server.compactSplitThread.requestCompaction(region, store, "Recursive enqueue",
attributes);
we are inside old CompactionRequest, so we could just pass "this" instead of
attributes all the way down, and coproc would get attributes if it needs to.
That way HBase code doesn't even have to know attributes exist inside
coproc-subclasses CompactionRequest.
{quote}
The question to me came down to be whether the re-enque is supposed to be a
'new' compaction request or a re-attempt at the same compaction. In the
existing code, its a brand new compaction request that just happens to be on
the same region and store.
So, do we pass along the original attributes or do we make it a 'system
created' compaction, separate from the original request?
My inclination was to pass the same attributes back along again. Therefore, for
example, the CP that creates the CompactionRequest can check the attributes and
make a decision as to whether or not it should modify the compaction ("Oh, I
already made this request! That means I need to ..."). Likely, you aren't going
to want to do anything again, but this is a bit more logic and knowledge of the
compaction architecture than most people are going to want to deal with ("What,
why am I getting this request again! The one I ran is done!"). But this is CPs
and you are supposed to have the rope to hang yourself :)
The flip side is that we consider this a 'system' compaction separate from the
user requested one and just pass in null attributes. This is nice in that its
cleaner (no leaked attributes) and logically is a different operation from the
original one that that client started. For instance, suppose the client starts
a compaction, but their compaction doesn't do actually change the number of
files. If we have a blocking number of store files we could re-enque that
compaction as a regular system operation.
Thoughts? I could go either way.
> Add generic attributes to CP initiated compaction request AND latch on
> compaction completion
> --------------------------------------------------------------------------------------------
>
> Key: HBASE-7725
> URL: https://issues.apache.org/jira/browse/HBASE-7725
> Project: HBase
> Issue Type: Bug
> Components: Compaction, Coprocessors, regionserver
> Reporter: Jesse Yates
> Assignee: Jesse Yates
> Fix For: 0.96.0, 0.94.6
>
> Attachments: example.java, hbase-7725_0.94-v0.patch,
> hbase-7725-v0.patch, hbase-7725-v1.patch, hbase-7725-v3.patch,
> hbase-7725_with-attributes-0.94-v0.patch,
> hbase-7725_with-attributes-0.94-v1.patch
>
>
> You can request that a compaction be started, but you can't be sure when that
> compaction request completes. This is a simple update to the
> CompactionRequest interface and the compact-split thread on the RS that
> doesn't actually impact the RS exposed interface.
> This is particularly useful for CPs so they can control starting/running a
> compaction.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
