hbase-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Ted Yu (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (HBASE-15075) Allow region split request to carry metadata
Date Tue, 12 Jan 2016 01:56:39 GMT

    [ https://issues.apache.org/jira/browse/HBASE-15075?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15093126#comment-15093126

Ted Yu commented on HBASE-15075:

bq. The description on this issue implies something generic

When I logged this JIRA, that was the intention. However, working out a patch, I realized
that the metadata has to go through RPC layer using protobuf. This narrows the choice for
the data type used.
Subject of the JIRA can be modified to reflect the actual approach.

bq. Why use UUID? Why not a random long?

UUID gives us wider scope for the purpose of identification of split requests. Meaning, for
long running region servers, the chance of collision between UUIDs is very low. As for type
long, the chance of collision is higher.

bq. Should we add API so split requests can pass arbitrary metadata as issue description implies?

I would be willing to see how the arbitrary metadata should be formulated. Keep in mind that
such metadata needs to be protobuf'ed.
For the use cases I am aware of, UUID suffices.

bq. Should every request type be extended like this? I.e. merge transactions?

Depending on the outcome of discussion for this JIRA, I think the adopted solution can be
applied for merge request as well (maybe in another JIRA).

> Allow region split request to carry metadata
> --------------------------------------------
>                 Key: HBASE-15075
>                 URL: https://issues.apache.org/jira/browse/HBASE-15075
>             Project: HBase
>          Issue Type: Improvement
>            Reporter: Ted Yu
>            Assignee: Ted Yu
>         Attachments: 15075-v0.txt, 15075-v1.txt, 15075-v2.txt, HBASE-15075.v2.patch,
> During the process of improving region normalization feature, I found that if region
split request triggered by the execution of SplitNormalizationPlan fails, there is no way
of knowing whether the failed split originated from region normalization.
> The association of particular split request with outcome of split would give RegionNormalizer
information so that it can make better normalization decisions in the subsequent invocations.
> One approach is to embed metadata in SplitRequest which gets passed through RegionStateTransitionContext
when RegionServerServices#reportRegionStateTransition() is called.
> This way, RegionStateListener can be notified with the metadata (id of the requester).
> See discussion on dev mailing list
> http://search-hadoop.com/m/YGbbCXdkivihp2

This message was sent by Atlassian JIRA

View raw message