hbase-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Jesse Yates (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (HBASE-7725) Add generic attributes to CP initiated compaction request AND latch on compaction completion
Date Fri, 15 Feb 2013 06:57:16 GMT

    [ 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

Mime
View raw message