[jira] [Created] (HBASE-16419) check REPLICATION_SCOPE's value more stringent

[Guangxu Cheng (JIRA)]

Guangxu Cheng created HBASE-16419:
-

 Summary: check REPLICATION_SCOPE's value more stringent
 Key: HBASE-16419
 URL: https://issues.apache.org/jira/browse/HBASE-16419
 Project: HBase
  Issue Type: Bug
  Components: master
Affects Versions: 1.2.2, 2.0.0
Reporter: Guangxu Cheng


When create table or modify table, the master will check if the value of 
REPLICATION_SCOPE is less than 0, however the value of REPLICATION_SCOPE must 
be 0 or 1. Otherwise will lead to  regionserver shutdown, so I think should be 
check the values of REPLICATION_SCOPE more stringent.

Beginning I don't fully understand the usage of REPLICATION_SCOPE, then set 
REPLICATION_SCOPE to 2 by mistake.when I insert data to table,the regionservers 
abort one by one,finanly
the cluster abort，the exceptions as follow:
{quote}
2016-08-16 12:34:45,245 WARN  [regionserver/host:60023.append-pool1-t1] 
wal.FSHLog: Append sequenceId=94, requesting roll of WAL
java.lang.NullPointerException
at 
org.apache.hadoop.hbase.protobuf.generated.WALProtos$FamilyScope$Builder.setScopeType(WALProtos.java:3939)
at org.apache.hadoop.hbase.wal.WALKey.getBuilder(WALKey.java:618)
at 
org.apache.hadoop.hbase.regionserver.wal.ProtobufLogWriter.append(ProtobufLogWriter.java:118)
at 
org.apache.hadoop.hbase.regionserver.wal.FSHLog$RingBufferEventHandler.append(FSHLog.java:1886)
at 
org.apache.hadoop.hbase.regionserver.wal.FSHLog$RingBufferEventHandler.onEvent(FSHLog.java:1750)
at 
org.apache.hadoop.hbase.regionserver.wal.FSHLog$RingBufferEventHandler.onEvent(FSHLog.java:1672)
at 
com.lmax.disruptor.BatchEventProcessor.run(BatchEventProcessor.java:128)
at 
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
at 
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
at java.lang.Thread.run(Thread.java:744)
2016-08-16 12:34:45,293 INFO  [MemStoreFlusher.0] regionserver.HStore: Added 
hdfs://hbase-test-27/hbase1.2.2/data/default/usertable/2aa98c17845c9c6d5c8760b87b3ba09a/i/35825c94e72945c0bf7df3f0adefa1b6,
 entries=1161600, sequenceid=59, filesize=167.6 M
2016-08-16 12:34:45,296 FATAL [MemStoreFlusher.0] regionserver.HRegionServer: 
ABORTING region server hbase-10-166-141-99,60023,1471262434177: Replay of WAL 
required. Forcing server shutdown
org.apache.hadoop.hbase.DroppedSnapshotException: region: 
usertable,,1471262560009.2aa98c17845c9c6d5c8760b87b3ba09a.
at 
org.apache.hadoop.hbase.regionserver.HRegion.internalFlushCacheAndCommit(HRegion.java:2427)
at 
org.apache.hadoop.hbase.regionserver.HRegion.internalFlushcache(HRegion.java:2105)
at 
org.apache.hadoop.hbase.regionserver.HRegion.internalFlushcache(HRegion.java:2067)
at 
org.apache.hadoop.hbase.regionserver.HRegion.flushcache(HRegion.java:1958)
at org.apache.hadoop.hbase.regionserver.HRegion.flush(HRegion.java:1884)
at 
org.apache.hadoop.hbase.regionserver.MemStoreFlusher.flushRegion(MemStoreFlusher.java:510)
at 
org.apache.hadoop.hbase.regionserver.MemStoreFlusher.flushRegion(MemStoreFlusher.java:471)
at 
org.apache.hadoop.hbase.regionserver.MemStoreFlusher.access$900(MemStoreFlusher.java:75)
at 
org.apache.hadoop.hbase.regionserver.MemStoreFlusher$FlushHandler.run(MemStoreFlusher.java:259)
at java.lang.Thread.run(Thread.java:744)
Caused by: org.apache.hadoop.hbase.regionserver.wal.DamagedWALException: Append 
sequenceId=94, requesting roll of WAL
at 
org.apache.hadoop.hbase.regionserver.wal.FSHLog$RingBufferEventHandler.append(FSHLog.java:1898)
at 
org.apache.hadoop.hbase.regionserver.wal.FSHLog$RingBufferEventHandler.onEvent(FSHLog.java:1750)
at 
org.apache.hadoop.hbase.regionserver.wal.FSHLog$RingBufferEventHandler.onEvent(FSHLog.java:1672)
at 
com.lmax.disruptor.BatchEventProcessor.run(BatchEventProcessor.java:128)
at 
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
at 
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
... 1 more
Caused by: java.lang.NullPointerException
at 
org.apache.hadoop.hbase.protobuf.generated.WALProtos$FamilyScope$Builder.setScopeType(WALProtos.java:3939)
at org.apache.hadoop.hbase.wal.WALKey.getBuilder(WALKey.java:618)
at 
org.apache.hadoop.hbase.regionserver.wal.ProtobufLogWriter.append(ProtobufLogWriter.java:118)
at 
org.apache.hadoop.hbase.regionserver.wal.FSHLog$RingBufferEventHandler.append(FSHLog.java:1886)
... 6 more
{quote}



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

Re: Source incompatibility between 1.2.[0,1] and 1.2.2 breaks Phoenix

[张铎]

Yes, with jdk8 we could add new methods in interface without breaking the
sub classes.

So let's revert HBASE-15645 from branch-1 and branch-1,x and add default
implementations in master? Is yetus OK to run pre-commit with jdk8 only on
master now?

Thanks.

2016-08-16 13:12 GMT+08:00 Sean Busbey :

> On Tue, Aug 16, 2016 at 12:09 AM, Sean Busbey  wrote:
>
> >
> > Moving from interfaces to abstract classes requires a deprecation cycle,
> > so to transition I think we'd need to introduce a new API. Anyone up for
> > this in 2.0?
> >
>
> I just remembered that HBase 2.0 is moving to jdk8+, which means we could
> use default methods when adding to existing interfaces, so there's
> substantially less draw for moving to abstract classes.
>

Re: Source incompatibility between 1.2.[0,1] and 1.2.2 breaks Phoenix

[Stack]

On Mon, Aug 15, 2016 at 10:09 PM, Sean Busbey  wrote:

> On Mon, Aug 15, 2016 at 10:55 PM, Andrew Purtell  >
> wrote:
>
> > > Are we extending this to all interfaces? Do we support folks
> > implementing their own Connection? Admin?
> >
> >  This will bury us in weeds and bikeshedding. We can make a blanket rule
> > about source compatibility appropriately scoped to minors and/or patches
> > without that drama. To wit:
> >
> > > So when I read the existing guides, what I see is that we're supposed
> to
> > be _source_ compatible on minor and patch releases, but binary compatible
> > only on patch
> >
> > We should take the opportunity to clarify the language of the
> > compatibility guide. And if the above is the policy then the change to
> > Table is not allowed.
> >
> >
> so "yes". :)  Works for me.
>
>
I'm good on the blanket rule on source and binary fix to spec. going
forward and a 1.2.3 tout de suite with revert of HBASE-15645
.
St.Ack

Re: Source incompatibility between 1.2.[0,1] and 1.2.2 breaks Phoenix

[Sean Busbey]

On Tue, Aug 16, 2016 at 12:09 AM, Sean Busbey  wrote:

>
> Moving from interfaces to abstract classes requires a deprecation cycle,
> so to transition I think we'd need to introduce a new API. Anyone up for
> this in 2.0?
>

I just remembered that HBase 2.0 is moving to jdk8+, which means we could
use default methods when adding to existing interfaces, so there's
substantially less draw for moving to abstract classes.

Re: Source incompatibility between 1.2.[0,1] and 1.2.2 breaks Phoenix

[Sean Busbey]

On Mon, Aug 15, 2016 at 10:55 PM, Andrew Purtell 
wrote:

> > Are we extending this to all interfaces? Do we support folks
> implementing their own Connection? Admin?
>
>  This will bury us in weeds and bikeshedding. We can make a blanket rule
> about source compatibility appropriately scoped to minors and/or patches
> without that drama. To wit:
>
> > So when I read the existing guides, what I see is that we're supposed to
> be _source_ compatible on minor and patch releases, but binary compatible
> only on patch
>
> We should take the opportunity to clarify the language of the
> compatibility guide. And if the above is the policy then the change to
> Table is not allowed.
>
>
so "yes". :)  Works for me.

Moving from interfaces to abstract classes requires a deprecation cycle, so
to transition I think we'd need to introduce a new API. Anyone up for this
in 2.0?

[RESULT] [VOTE] The 2nd HBase 0.98.21 release candidate (RC1) is available

[Andrew Purtell]

I'm also +1

With 5 +1 votes (4 +1s binding) and no 0 or -1 votes, the vote passes. I
will send out the release announcement shortly.

Thanks to all who voted on the release candidate!

Thanks again for open sourcing clusterdock, Dima. It's been super helpful.


On Mon, Aug 8, 2016 at 8:45 PM, Andrew Purtell  wrote:

> ​​The 2nd HBase 0.98.21 release candidate (RC1) is available for download
> at https://dist.apache.org/repos/dist/dev/hbase/hbase-0.98.21RC1/ and
> Maven artifacts are also available in the temporary repository
> https://repository.apache.org/content/repositories/orgapachehbase-1145/ .
>
> The detailed source and binary compatibility report for this release with
> respect to the previous is available for your review at
> https://dist.apache.org/repos/dist/dev/hbase/hbase-0.98.
> 21RC1/HBase_0.98.20_to_0.98.21RC1_compatibility_report.html . There is
> one change of note: an allowable change to Public/Evolving
> HFilePrettyPrinter introduced as part of a security fix.
>
> The 57 issues resolved in this release can be found at
> https://s.apache.org/SfDQ .
>
> I have made the following assessments of this candidate:
> - Release audit check passes
> - Unit test suite passes (7u79)
> - Loaded 1M keys with LTT (10 readers, 10 writers, 10 updaters (20%): all
> keys verified, no unusual messages or errors, latencies in the ballpark
> - IntegrationTestBigLinkedList writing 500M keys with slowDeterministic
> chaos policy in effect: result is 100% referenced, no verification errors
> (8u91)
> - Built head of Apache Phoenix 4.x-HBase-0.98 branch, looks good (7u79)
>
> Signed with my code signing key D5365CCD.
>
> Please try out the candidate and vote +1/0/-1. This vote will be open for
> at least 72 hours. Unless objection I will try to close it Monday August
> 15, 2016 if we have sufficient votes.
>
> --
> Best regards,
>
>- Andy
>
> Problems worthy of attack prove their worth by hitting back. - Piet Hein
> (via Tom White)
>



-- 
Best regards,

   - Andy

Problems worthy of attack prove their worth by hitting back. - Piet Hein
(via Tom White)

Re: Source incompatibility between 1.2.[0,1] and 1.2.2 breaks Phoenix

[ramkrishna vasudevan]

I agree with Sean here.
Interfaces with @Private annotations are going to be a problem. I think we
should strongly discourage this. Either allow abstract classes are don't
allow such things. We should have a note about this in the compatibility
guide.

Even regarding the Util classes and the respective static methods - though
we mark APIs private, if we change or remove those APIs still it will have
compatability issues?  We are following a practice of deprecating any API
in such Util classes and removing them only in major APIs but the ones
marked as @Private may be source of problem.

Regards
Ram

On Tue, Aug 16, 2016 at 9:25 AM, Andrew Purtell 
wrote:

> > Are we extending this to all interfaces? Do we support folks
> implementing their own Connection? Admin?
>
>  This will bury us in weeds and bikeshedding. We can make a blanket rule
> about source compatibility appropriately scoped to minors and/or patches
> without that drama. To wit:
>
> > So when I read the existing guides, what I see is that we're supposed to
> be _source_ compatible on minor and patch releases, but binary compatible
> only on patch
>
> We should take the opportunity to clarify the language of the
> compatibility guide. And if the above is the policy then the change to
> Table is not allowed.
>
>
> > On Aug 15, 2016, at 8:26 PM, Sean Busbey  wrote:
> >
> > Thanks for bringing this up Josh!
> >
> >
> >
> > On Mon, Aug 15, 2016 at 2:21 PM, Andrew Purtell 
> wrote:
> >
> >> ​
> >> I find the InterfaceAudience annotations on this really strange. How can
> >> we have a Public audience Interface (o.a.h.h.c.Table) with Private
> methods?
> >>
> >> I'm also not sure the Private annotations on the Table interface are
> that
> >> useful. Any change to an interface renders it source incompatible, and
> >> removal (or effective removal via signature change) of methods from an
> >> interface introduces a binary incompatibility. I think the Private
> >> annotations on methods of a Public interface imply we should refactor
> those
> >> methods to a non-public interface.
> >>
> >
> >
> > Generally, we use more restricted audience annotations on members within
> a
> > given API to show where there are limits on our support that we can't
> > express in Java access modifiers. I think it's important for us to keep
> > this around so that we can avoid a proliferation of "FooUtil" and other
> > classes that exist just to make a Public/Private distinction. (I
> recognize
> > we have several of these but I was hoping we'd move in the direction of
> > fewer over time.)
> >
> > I agree that in the case of interfaces it's problematic, since we have no
> > way to distinguish between "should be consumed" and "can be extended".
> > Perhaps we should make sure we have abstract classes instead of
> interfaces?
> > We could also add an annotation to make the consumed/extended
> distinction;
> > I've seen it come up a few times in other users of audience annotations.
> >
> >
> >
> >> ​
> >> Now that we've had quite a few releases in the "not-quite-SemVer"
> >> compatibility guide, is there any interest in trying to make the
> >> compatibility guarantees more stringent?
> >>
> >> I was looking at our compat guidelines (
> >> http://hbase.apache.org/book.html#hbase.versioning) and think we could
> >> make
> >> a few refinements.
> >>
> >> We make several allowances for public interface changes that are binary
> >> compatible but not source compatible in patch releases. I think we are
> only
> >> taking into consideration callers but should also consider implementors
> of
> >> public interfaces. Changing a public interface on a patch release
> renders
> >> it source incompatible. Can we avoid doing that on *patch* releases, and
> >> restrict this type of change to minors?
> > Are we extending this to all interfaces? Do we support folks implementing
> > their own Connection? Admin?
> >
> >
> >> Although we make allowances for public interface changes that are binary
> >> compatible we also say "A minor upgrade requires no application/client
> code
> >> modification." which could imply source compatibility even across
> minors,
> >> which I believe is not the intent.
> >>
> >> We could add a source compatibility dimension for patch releases.
> >>
> >>
> >> ​
> >> I would like to see us get to source-compatibility on patch releases,
> not
> >> just binary compatibility
> >>
> >> You mean source compatibility for Public annotated interfaces only,
> right?
> >>
> >> In that case evaluating compliance would be easy: RMs would run the API
> >> compat checker on a RC and if a patch release the number of binary and
> >> source compat issues should both be zero.
> > So when I read the existing guides, what I see is that we're supposed to
> be
> > _source_ compatible on minor and patch releases, but binary compatible
> only
> > on patch releases. I think we discussed this a year or two ago, and IIRC
> > the reasoning was that since we maintain wire compatibility on minor and
> 

Re: Source incompatibility between 1.2.[0,1] and 1.2.2 breaks Phoenix

[Andrew Purtell]

> Are we extending this to all interfaces? Do we support folks implementing 
> their own Connection? Admin?

 This will bury us in weeds and bikeshedding. We can make a blanket rule about 
source compatibility appropriately scoped to minors and/or patches without that 
drama. To wit:

> So when I read the existing guides, what I see is that we're supposed to be 
> _source_ compatible on minor and patch releases, but binary compatible only 
> on patch

We should take the opportunity to clarify the language of the compatibility 
guide. And if the above is the policy then the change to Table is not allowed. 


> On Aug 15, 2016, at 8:26 PM, Sean Busbey  wrote:
> 
> Thanks for bringing this up Josh!
> 
> 
> 
> On Mon, Aug 15, 2016 at 2:21 PM, Andrew Purtell  wrote:
> 
>> ​
>> I find the InterfaceAudience annotations on this really strange. How can
>> we have a Public audience Interface (o.a.h.h.c.Table) with Private methods?
>> 
>> I'm also not sure the Private annotations on the Table interface are that
>> useful. Any change to an interface renders it source incompatible, and
>> removal (or effective removal via signature change) of methods from an
>> interface introduces a binary incompatibility. I think the Private
>> annotations on methods of a Public interface imply we should refactor those
>> methods to a non-public interface.
>> 
> 
> 
> Generally, we use more restricted audience annotations on members within a
> given API to show where there are limits on our support that we can't
> express in Java access modifiers. I think it's important for us to keep
> this around so that we can avoid a proliferation of "FooUtil" and other
> classes that exist just to make a Public/Private distinction. (I recognize
> we have several of these but I was hoping we'd move in the direction of
> fewer over time.)
> 
> I agree that in the case of interfaces it's problematic, since we have no
> way to distinguish between "should be consumed" and "can be extended".
> Perhaps we should make sure we have abstract classes instead of interfaces?
> We could also add an annotation to make the consumed/extended distinction;
> I've seen it come up a few times in other users of audience annotations.
> 
> 
> 
>> ​
>> Now that we've had quite a few releases in the "not-quite-SemVer"
>> compatibility guide, is there any interest in trying to make the
>> compatibility guarantees more stringent?
>> 
>> I was looking at our compat guidelines (
>> http://hbase.apache.org/book.html#hbase.versioning) and think we could
>> make
>> a few refinements.
>> 
>> We make several allowances for public interface changes that are binary
>> compatible but not source compatible in patch releases. I think we are only
>> taking into consideration callers but should also consider implementors of
>> public interfaces. Changing a public interface on a patch release renders
>> it source incompatible. Can we avoid doing that on *patch* releases, and
>> restrict this type of change to minors?
> Are we extending this to all interfaces? Do we support folks implementing
> their own Connection? Admin?
> 
> 
>> Although we make allowances for public interface changes that are binary
>> compatible we also say "A minor upgrade requires no application/client code
>> modification." which could imply source compatibility even across minors,
>> which I believe is not the intent.
>> 
>> We could add a source compatibility dimension for patch releases.
>> 
>> 
>> ​
>> I would like to see us get to source-compatibility on patch releases, not
>> just binary compatibility
>> 
>> You mean source compatibility for Public annotated interfaces only, right?
>> 
>> In that case evaluating compliance would be easy: RMs would run the API
>> compat checker on a RC and if a patch release the number of binary and
>> source compat issues should both be zero.
> So when I read the existing guides, what I see is that we're supposed to be
> _source_ compatible on minor and patch releases, but binary compatible only
> on patch releases. I think we discussed this a year or two ago, and IIRC
> the reasoning was that since we maintain wire compatibility on minor and
> patch releases, those who need to ignore a given set of binary incompatible
> changes can just make use of the older library.

Re: Source incompatibility between 1.2.[0,1] and 1.2.2 breaks Phoenix

[Sean Busbey]

Sorry I missed this other thing I wanted to comment on:



On Mon, Aug 15, 2016 at 2:07 PM, Josh Elser  wrote:

>
>
>
> 3) What do people think about changing this in a 1.2.3 with a quick
> turn-around?
>
>
I'm actually behind cadence for 1.2.3 by about a week, so I'm fine with
getting that release out whenever we have a consensus solution to this
issue.

Re: Can anyone explain tome about the 2 unit tests in hbase-client have the same code?

[Ted Yu]

Not sure what  scenario testRegionServerStoppedOnScannerOpen() intended to
test.

Looks like testRegionServerStoppedOnScannerOpen() can be dropped.

On Mon, Aug 15, 2016 at 8:13 PM, Huang, Zhi  wrote:

> Hi,
> I am reading the test code in hbase, and I found in this test class:
> https://github.com/apache/hbase/blob/master/hbase-
> client/src/test/java/org/apache/hadoop/hbase/client/
> TestClientNoCluster.java
> in line 233 and line 244: the method codes are exactly the same! When one
> fails, how do you know where the problem is ?
>
> Looking forward to your reply!
>
>

Re: Source incompatibility between 1.2.[0,1] and 1.2.2 breaks Phoenix

[Sean Busbey]

Thanks for bringing this up Josh!



On Mon, Aug 15, 2016 at 2:21 PM, Andrew Purtell  wrote:

> >
> ​
>  I find the InterfaceAudience annotations on this really strange. How can
> we have a Public audience Interface (o.a.h.h.c.Table) with Private methods?
>
> I'm also not sure the Private annotations on the Table interface are that
> useful. Any change to an interface renders it source incompatible, and
> removal (or effective removal via signature change) of methods from an
> interface introduces a binary incompatibility. I think the Private
> annotations on methods of a Public interface imply we should refactor those
> methods to a non-public interface.
>
> >
>


Generally, we use more restricted audience annotations on members within a
given API to show where there are limits on our support that we can't
express in Java access modifiers. I think it's important for us to keep
this around so that we can avoid a proliferation of "FooUtil" and other
classes that exist just to make a Public/Private distinction. (I recognize
we have several of these but I was hoping we'd move in the direction of
fewer over time.)

I agree that in the case of interfaces it's problematic, since we have no
way to distinguish between "should be consumed" and "can be extended".
Perhaps we should make sure we have abstract classes instead of interfaces?
We could also add an annotation to make the consumed/extended distinction;
I've seen it come up a few times in other users of audience annotations.



> ​
> Now that we've had quite a few releases in the "not-quite-SemVer"
> compatibility guide, is there any interest in trying to make the
> compatibility guarantees more stringent?
>
> I was looking at our compat guidelines (
> http://hbase.apache.org/book.html#hbase.versioning) and think we could
> make
> a few refinements.
>
> We make several allowances for public interface changes that are binary
> compatible but not source compatible in patch releases. I think we are only
> taking into consideration callers but should also consider implementors of
> public interfaces. Changing a public interface on a patch release renders
> it source incompatible. Can we avoid doing that on *patch* releases, and
> restrict this type of change to minors?
>
>
Are we extending this to all interfaces? Do we support folks implementing
their own Connection? Admin?


> Although we make allowances for public interface changes that are binary
> compatible we also say "A minor upgrade requires no application/client code
> modification." which could imply source compatibility even across minors,
> which I believe is not the intent.
>
> We could add a source compatibility dimension for patch releases.
>
>
> ​
> I would like to see us get to source-compatibility on patch releases, not
> just binary compatibility
>
> You mean source compatibility for Public annotated interfaces only, right?
>
> In that case evaluating compliance would be easy: RMs would run the API
> compat checker on a RC and if a patch release the number of binary and
> source compat issues should both be zero.
>
>
So when I read the existing guides, what I see is that we're supposed to be
_source_ compatible on minor and patch releases, but binary compatible only
on patch releases. I think we discussed this a year or two ago, and IIRC
the reasoning was that since we maintain wire compatibility on minor and
patch releases, those who need to ignore a given set of binary incompatible
changes can just make use of the older library.

Can anyone explain tome about the 2 unit tests in hbase-client have the same code?

[Huang, Zhi]

Hi,
I am reading the test code in hbase, and I found in this test class:
https://github.com/apache/hbase/blob/master/hbase-client/src/test/java/org/apache/hadoop/hbase/client/TestClientNoCluster.java
in line 233 and line 244: the method codes are exactly the same! When one 
fails, how do you know where the problem is ?

Looking forward to your reply!

Re: Source incompatibility between 1.2.[0,1] and 1.2.2 breaks Phoenix

[Dima Spivak]

I have HBASE-16158 open to run check_compatibility.sh as part of our Yetus
personality, I just got sidetracked by other work. Let me try to get
something up by week's end.

-Dima

On Mon, Aug 15, 2016 at 5:15 PM, Stack  wrote:

> On Mon, Aug 15, 2016 at 12:21 PM, Andrew Purtell 
> wrote:
>
> > ...
>
>
> > I was looking at our compat guidelines (
> > http://hbase.apache.org/book.html#hbase.versioning) and think we could
> > make
> > a few refinements.
> >
> > We make several allowances for public interface changes that are binary
> > compatible but not source compatible in patch releases. I think we are
> only
> > taking into consideration callers but should also consider implementors
> of
> > public interfaces. Changing a public interface on a patch release renders
> > it source incompatible. Can we avoid doing that on *patch* releases, and
> > restrict this type of change to minors?
> >
> > Although we make allowances for public interface changes that are binary
> > compatible we also say "A minor upgrade requires no application/client
> code
> > modification." which could imply source compatibility even across minors,
> > which I believe is not the intent.
> >
> > We could add a source compatibility dimension for patch releases.
> >
> >
>
> Makes sense Andrew.
>
>
>
> > >
> > ​
> > I would like to see us get to source-compatibility on patch releases, not
> > just binary compatibility
> >
> > You mean source compatibility for Public annotated interfaces only,
> right?
> >
> > In that case evaluating compliance would be easy: RMs would run the API
> > compat checker on a RC and if a patch release the number of binary and
> > source compat issues should both be zero.
> >
> >
> Can we have yetus report on compat?
>
> I'd be up for helping get out a 1.2.3 (and a fix in 1.1.6) to address this
> compat hiccup especially given I was party to the change. I +1'd and
> committed the patch thinking addition of methods ok not thinking of the
> Table implementors.
>
> St.Ack
>
>
>
>
> >
> > On Mon, Aug 15, 2016 at 12:07 PM, Josh Elser 
> wrote:
> >
> > > Hi folks,
> > >
> > > I just noticed a ticket over in Phoenix [1] in which some method
> > additions
> > > to the Table interface [2] breaks the source compatibility of Phoenix
> > with
> > > HBase 1.2.2.
> > >
> > > My understanding of the current guidelines is that these are allowed as
> > > they do not invalidate binary compatibility of clients using the API.
> > > Personally, I am very hard-pressed to use the word "compatible" in a
> > > sentence describing this change that isn't sarcastic :)
> > >
> > > A couple of questions:
> > >
> > > 1)
> > > ​​
> > > I find the InterfaceAudience annotations on this really strange. How
> can
> > > we have a Public audience Interface (o.a.h.h.c.Table) with Private
> > methods?
> > > Is that just "how things are", or am I missing something? If this is
> not
> > > something that's meant to be public, I would think these new methods
> > should
> > > be defined in a non-public interface.
> > >
> > > 2)
> > > ​​
> > > Now that we've had quite a few releases in the "not-quite-SemVer"
> > > compatibility guide, is there any interest in trying to make the
> > > compatibility guarantees more stringent?
> > > ​​
> > > I would like to see us get to source-compatibility on patch releases,
> not
> > > just binary compatibility. I am happy to try to help, but I know I
> don't
> > > have the time to devote to catch everything.
> > >
> > > 3) What do people think about changing this in a 1.2.3 with a quick
> > > turn-around?
> > >
> > > Thanks!
> > >
> > > - Josh
> > >
> > > [1] https://issues.apache.org/jira/browse/PHOENIX-3116
> > > [2] https://issues.apache.org/jira/browse/HBASE-15645
> > >
> >
> >
> >
> > --
> > Best regards,
> >
> >- Andy
> >
> > Problems worthy of attack prove their worth by hitting back. - Piet Hein
> > (via Tom White)
> >
>



-- 
-Dima

Re: Source incompatibility between 1.2.[0,1] and 1.2.2 breaks Phoenix

[Stack]

On Mon, Aug 15, 2016 at 12:21 PM, Andrew Purtell 
wrote:

> ...


> I was looking at our compat guidelines (
> http://hbase.apache.org/book.html#hbase.versioning) and think we could
> make
> a few refinements.
>
> We make several allowances for public interface changes that are binary
> compatible but not source compatible in patch releases. I think we are only
> taking into consideration callers but should also consider implementors of
> public interfaces. Changing a public interface on a patch release renders
> it source incompatible. Can we avoid doing that on *patch* releases, and
> restrict this type of change to minors?
>
> Although we make allowances for public interface changes that are binary
> compatible we also say "A minor upgrade requires no application/client code
> modification." which could imply source compatibility even across minors,
> which I believe is not the intent.
>
> We could add a source compatibility dimension for patch releases.
>
>

Makes sense Andrew.



> >
> ​
> I would like to see us get to source-compatibility on patch releases, not
> just binary compatibility
>
> You mean source compatibility for Public annotated interfaces only, right?
>
> In that case evaluating compliance would be easy: RMs would run the API
> compat checker on a RC and if a patch release the number of binary and
> source compat issues should both be zero.
>
>
Can we have yetus report on compat?

I'd be up for helping get out a 1.2.3 (and a fix in 1.1.6) to address this
compat hiccup especially given I was party to the change. I +1'd and
committed the patch thinking addition of methods ok not thinking of the
Table implementors.

St.Ack




>
> On Mon, Aug 15, 2016 at 12:07 PM, Josh Elser  wrote:
>
> > Hi folks,
> >
> > I just noticed a ticket over in Phoenix [1] in which some method
> additions
> > to the Table interface [2] breaks the source compatibility of Phoenix
> with
> > HBase 1.2.2.
> >
> > My understanding of the current guidelines is that these are allowed as
> > they do not invalidate binary compatibility of clients using the API.
> > Personally, I am very hard-pressed to use the word "compatible" in a
> > sentence describing this change that isn't sarcastic :)
> >
> > A couple of questions:
> >
> > 1)
> > ​​
> > I find the InterfaceAudience annotations on this really strange. How can
> > we have a Public audience Interface (o.a.h.h.c.Table) with Private
> methods?
> > Is that just "how things are", or am I missing something? If this is not
> > something that's meant to be public, I would think these new methods
> should
> > be defined in a non-public interface.
> >
> > 2)
> > ​​
> > Now that we've had quite a few releases in the "not-quite-SemVer"
> > compatibility guide, is there any interest in trying to make the
> > compatibility guarantees more stringent?
> > ​​
> > I would like to see us get to source-compatibility on patch releases, not
> > just binary compatibility. I am happy to try to help, but I know I don't
> > have the time to devote to catch everything.
> >
> > 3) What do people think about changing this in a 1.2.3 with a quick
> > turn-around?
> >
> > Thanks!
> >
> > - Josh
> >
> > [1] https://issues.apache.org/jira/browse/PHOENIX-3116
> > [2] https://issues.apache.org/jira/browse/HBASE-15645
> >
>
>
>
> --
> Best regards,
>
>- Andy
>
> Problems worthy of attack prove their worth by hitting back. - Piet Hein
> (via Tom White)
>

[jira] [Created] (HBASE-16418) Reduce duration of sleep waiting for region reopen in IntegrationTestBulkLoad#installSlowingCoproc()

[Ted Yu (JIRA)]

Ted Yu created HBASE-16418:
--

 Summary: Reduce duration of sleep waiting for region reopen in 
IntegrationTestBulkLoad#installSlowingCoproc()
 Key: HBASE-16418
 URL: https://issues.apache.org/jira/browse/HBASE-16418
 Project: HBase
  Issue Type: Test
Reporter: Ted Yu
Priority: Minor


Currently we have the following code:
{code}
desc.addCoprocessor(SlowMeCoproScanOperations.class.getName());
HBaseTestingUtility.modifyTableSync(admin, desc);
//sleep for sometime. Hope is that the regions are closed/opened before
//the sleep returns. TODO: do this better
Thread.sleep(3);
{code}
Instead of sleeping for fixed duration, we should detect when the regions have 
reopened with custom Coprocessor.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

Re: Source incompatibility between 1.2.[0,1] and 1.2.2 breaks Phoenix

[Josh Elser]

Thanks for the great reply, Andrew!

Andrew Purtell wrote:

​
  I find the InterfaceAudience annotations on this really strange. How can
we have a Public audience Interface (o.a.h.h.c.Table) with Private methods?

I'm also not sure the Private annotations on the Table interface are that
useful. Any change to an interface renders it source incompatible, and
removal (or effective removal via signature change) of methods from an
interface introduces a binary incompatibility. I think the Private
annotations on methods of a Public interface imply we should refactor those
methods to a non-public interface.


I agree. This is how I would've expected to see such an 
non-public-facing method to have been added.



Now that we've had quite a few releases in the "not-quite-SemVer"
compatibility guide, is there any interest in trying to make the
compatibility guarantees more stringent?

I was looking at our compat guidelines (
http://hbase.apache.org/book.html#hbase.versioning) and think we could make
a few refinements.

We make several allowances for public interface changes that are binary
compatible but not source compatible in patch releases. I think we are only
taking into consideration callers but should also consider implementors of
public interfaces. Changing a public interface on a patch release renders
it source incompatible. Can we avoid doing that on *patch* releases, and
restrict this type of change to minors?

Although we make allowances for public interface changes that are binary
compatible we also say "A minor upgrade requires no application/client code
modification." which could imply source compatibility even across minors,
which I believe is not the intent.

We could add a source compatibility dimension for patch releases.


I like the way this sounds. Would it make sense to try to work on 
terminology to encapsulate this (after getting some more consensus that 
this is desirable)?



I would like to see us get to source-compatibility on patch releases, not
just binary compatibility

You mean source compatibility for Public annotated interfaces only, right?

In that case evaluating compliance would be easy: RMs would run the API
compat checker on a RC and if a patch release the number of binary and
source compat issues should both be zero.


Yes, sorry, I could've been more specified. Source-compatibility on the 
"public API" (defined presently by the Public audience annotation).

Successful: hbase.apache.org HTML Checker

[Apache Jenkins Server]

Successful

If successful, the HTML and link-checking report for http://hbase.apache.org is 
available at 
https://builds.apache.org/job/HBase%20Website%20Link%20Ckecker/56/artifact/link_report/index.html.

If failed, see 
https://builds.apache.org/job/HBase%20Website%20Link%20Ckecker/56/console.

Re: Source incompatibility between 1.2.[0,1] and 1.2.2 breaks Phoenix

[Andrew Purtell]

Also, the change to Table (HBASE-15645) went out in both 1.1.5 and 1.2.2.

On Mon, Aug 15, 2016 at 12:21 PM, Andrew Purtell 
wrote:

> >
> ​
>  I find the InterfaceAudience annotations on this really strange. How can
> we have a Public audience Interface (o.a.h.h.c.Table) with Private methods?
>
>
> I'm also not sure the Private annotations on the Table interface are that
> useful. Any change to an interface renders it source incompatible, and
> removal (or effective removal via signature change) of methods from an
> interface introduces a binary incompatibility. I think the Private
> annotations on methods of a Public interface imply we should refactor those
> methods to a non-public interface.
>
> >
> ​
> Now that we've had quite a few releases in the "not-quite-SemVer"
> compatibility guide, is there any interest in trying to make the
> compatibility guarantees more stringent?
>
> I was looking at our compat guidelines (http://hbase.apache.org/book.
> html#hbase.versioning) and think we could make a few refinements.
>
> We make several allowances for public interface changes that are binary
> compatible but not source compatible in patch releases. I think we are only
> taking into consideration callers but should also consider implementors of
> public interfaces. Changing a public interface on a patch release renders
> it source incompatible. Can we avoid doing that on *patch* releases, and
> restrict this type of change to minors?
>
> Although we make allowances for public interface changes that are binary
> compatible we also say "A minor upgrade requires no application/client code
> modification." which could imply source compatibility even across minors,
> which I believe is not the intent.
>
> We could add a source compatibility dimension for patch releases.
>
> >
> ​
> I would like to see us get to source-compatibility on patch releases, not
> just binary compatibility
>
> You mean source compatibility for Public annotated interfaces only, right?
>
> In that case evaluating compliance would be easy: RMs would run the API
> compat checker on a RC and if a patch release the number of binary and
> source compat issues should both be zero.
>
>
> On Mon, Aug 15, 2016 at 12:07 PM, Josh Elser  wrote:
>
>> Hi folks,
>>
>> I just noticed a ticket over in Phoenix [1] in which some method
>> additions to the Table interface [2] breaks the source compatibility of
>> Phoenix with HBase 1.2.2.
>>
>> My understanding of the current guidelines is that these are allowed as
>> they do not invalidate binary compatibility of clients using the API.
>> Personally, I am very hard-pressed to use the word "compatible" in a
>> sentence describing this change that isn't sarcastic :)
>>
>> A couple of questions:
>>
>> 1)
>> ​​
>> I find the InterfaceAudience annotations on this really strange. How can
>> we have a Public audience Interface (o.a.h.h.c.Table) with Private methods?
>> Is that just "how things are", or am I missing something? If this is not
>> something that's meant to be public, I would think these new methods should
>> be defined in a non-public interface.
>>
>> 2)
>> ​​
>> Now that we've had quite a few releases in the "not-quite-SemVer"
>> compatibility guide, is there any interest in trying to make the
>> compatibility guarantees more stringent?
>> ​​
>> I would like to see us get to source-compatibility on patch releases, not
>> just binary compatibility. I am happy to try to help, but I know I don't
>> have the time to devote to catch everything.
>>
>> 3) What do people think about changing this in a 1.2.3 with a quick
>> turn-around?
>>
>> Thanks!
>>
>> - Josh
>>
>> [1] https://issues.apache.org/jira/browse/PHOENIX-3116
>> [2] https://issues.apache.org/jira/browse/HBASE-15645
>>
>
>
>
> --
> Best regards,
>
>- Andy
>
> Problems worthy of attack prove their worth by hitting back. - Piet Hein
> (via Tom White)
>



-- 
Best regards,

   - Andy

Problems worthy of attack prove their worth by hitting back. - Piet Hein
(via Tom White)

Re: Source incompatibility between 1.2.[0,1] and 1.2.2 breaks Phoenix

[Andrew Purtell]

>
​
 I find the InterfaceAudience annotations on this really strange. How can
we have a Public audience Interface (o.a.h.h.c.Table) with Private methods?

I'm also not sure the Private annotations on the Table interface are that
useful. Any change to an interface renders it source incompatible, and
removal (or effective removal via signature change) of methods from an
interface introduces a binary incompatibility. I think the Private
annotations on methods of a Public interface imply we should refactor those
methods to a non-public interface.

>
​
Now that we've had quite a few releases in the "not-quite-SemVer"
compatibility guide, is there any interest in trying to make the
compatibility guarantees more stringent?

I was looking at our compat guidelines (
http://hbase.apache.org/book.html#hbase.versioning) and think we could make
a few refinements.

We make several allowances for public interface changes that are binary
compatible but not source compatible in patch releases. I think we are only
taking into consideration callers but should also consider implementors of
public interfaces. Changing a public interface on a patch release renders
it source incompatible. Can we avoid doing that on *patch* releases, and
restrict this type of change to minors?

Although we make allowances for public interface changes that are binary
compatible we also say "A minor upgrade requires no application/client code
modification." which could imply source compatibility even across minors,
which I believe is not the intent.

We could add a source compatibility dimension for patch releases.

>
​
I would like to see us get to source-compatibility on patch releases, not
just binary compatibility

You mean source compatibility for Public annotated interfaces only, right?

In that case evaluating compliance would be easy: RMs would run the API
compat checker on a RC and if a patch release the number of binary and
source compat issues should both be zero.


On Mon, Aug 15, 2016 at 12:07 PM, Josh Elser  wrote:

> Hi folks,
>
> I just noticed a ticket over in Phoenix [1] in which some method additions
> to the Table interface [2] breaks the source compatibility of Phoenix with
> HBase 1.2.2.
>
> My understanding of the current guidelines is that these are allowed as
> they do not invalidate binary compatibility of clients using the API.
> Personally, I am very hard-pressed to use the word "compatible" in a
> sentence describing this change that isn't sarcastic :)
>
> A couple of questions:
>
> 1)
> ​​
> I find the InterfaceAudience annotations on this really strange. How can
> we have a Public audience Interface (o.a.h.h.c.Table) with Private methods?
> Is that just "how things are", or am I missing something? If this is not
> something that's meant to be public, I would think these new methods should
> be defined in a non-public interface.
>
> 2)
> ​​
> Now that we've had quite a few releases in the "not-quite-SemVer"
> compatibility guide, is there any interest in trying to make the
> compatibility guarantees more stringent?
> ​​
> I would like to see us get to source-compatibility on patch releases, not
> just binary compatibility. I am happy to try to help, but I know I don't
> have the time to devote to catch everything.
>
> 3) What do people think about changing this in a 1.2.3 with a quick
> turn-around?
>
> Thanks!
>
> - Josh
>
> [1] https://issues.apache.org/jira/browse/PHOENIX-3116
> [2] https://issues.apache.org/jira/browse/HBASE-15645
>



-- 
Best regards,

   - Andy

Problems worthy of attack prove their worth by hitting back. - Piet Hein
(via Tom White)

Source incompatibility between 1.2.[0,1] and 1.2.2 breaks Phoenix

[Josh Elser]

Hi folks,

I just noticed a ticket over in Phoenix [1] in which some method 
additions to the Table interface [2] breaks the source compatibility of 
Phoenix with HBase 1.2.2.


My understanding of the current guidelines is that these are allowed as 
they do not invalidate binary compatibility of clients using the API. 
Personally, I am very hard-pressed to use the word "compatible" in a 
sentence describing this change that isn't sarcastic :)


A couple of questions:

1) I find the InterfaceAudience annotations on this really strange. How 
can we have a Public audience Interface (o.a.h.h.c.Table) with Private 
methods? Is that just "how things are", or am I missing something? If 
this is not something that's meant to be public, I would think these new 
methods should be defined in a non-public interface.


2) Now that we've had quite a few releases in the "not-quite-SemVer" 
compatibility guide, is there any interest in trying to make the 
compatibility guarantees more stringent? I would like to see us get to 
source-compatibility on patch releases, not just binary compatibility. I 
am happy to try to help, but I know I don't have the time to devote to 
catch everything.


3) What do people think about changing this in a 1.2.3 with a quick 
turn-around?


Thanks!

- Josh

[1] https://issues.apache.org/jira/browse/PHOENIX-3116
[2] https://issues.apache.org/jira/browse/HBASE-15645

Re: Someone please review HBASE-16318

[Sean Busbey]

Thanks Andrew!

On Mon, Aug 15, 2016 at 1:26 PM, Andrew Purtell  wrote:
> Done
>
> On Mon, Aug 15, 2016 at 7:31 AM, Sean Busbey  wrote:
>
>> Could someone please review the latest version of this change:
>>
>>
>> https://issues.apache.org/jira/browse/HBASE-16318
>>
>> It's the stop-gap to make sure we don't accidentally include dependencies
>> with prohibited licenses again. It took me a long time to get done and it's
>> sat without comment for nearly a week.
>>
>> --
>> busbey
>>
>
>
>
> --
> Best regards,
>
>- Andy
>
> Problems worthy of attack prove their worth by hitting back. - Piet Hein
> (via Tom White)



-- 
busbey

[jira] [Resolved] (HBASE-3489) .oldlogs not being cleaned out

[Dave Latham (JIRA)]

 [ 
https://issues.apache.org/jira/browse/HBASE-3489?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Dave Latham resolved HBASE-3489.

Resolution: Fixed

> .oldlogs not being cleaned out
> --
>
> Key: HBASE-3489
> URL: https://issues.apache.org/jira/browse/HBASE-3489
> Project: HBase
>  Issue Type: Bug
>Affects Versions: 0.90.0
> Environment: 10 Nodes Write Heavy Cluster
>Reporter: Wayne
> Attachments: oldlog.txt
>
>
> The .oldlogs folder is never being cleaned up. The 
> hbase.master.logcleaner.ttl has been set to clean up the old logs but the 
> clean up is never kicking in. The limit of 10 files is not the problem. After 
> running for 5 days not a single log file has ever been deleted and the 
> logcleaner is set to 2 days (from the default of 7 days). It is assumed that 
> the replication changes that want to be sure to keep these logs around if 
> needed have caused the cleanup to be blocked. There is no replication defined 
> (knowingly).
>  



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

Re: Someone please review HBASE-16318

[Andrew Purtell]

Done

On Mon, Aug 15, 2016 at 7:31 AM, Sean Busbey  wrote:

> Could someone please review the latest version of this change:
>
>
> https://issues.apache.org/jira/browse/HBASE-16318
>
> It's the stop-gap to make sure we don't accidentally include dependencies
> with prohibited licenses again. It took me a long time to get done and it's
> sat without comment for nearly a week.
>
> --
> busbey
>



-- 
Best regards,

   - Andy

Problems worthy of attack prove their worth by hitting back. - Piet Hein
(via Tom White)

Re: [VOTE] The 2nd HBase 0.98.21 release candidate (RC1) is available

[Dima Spivak]

+1

- Deployed onto a 5-node container cluster from binary tarball (with Hadoop
2.5.1). Did some sanity checks of the HBase shell and web UI, all looks
good.
- Ran IntegrationTestBigLinkedList in loop mode with 1 billion nodes;
passed without a problem with three different monkeys.

On Saturday, August 13, 2016, ramkrishna vasudevan <
ramkrishna.s.vasude...@gmail.com> wrote:

> +1
> Built from source. Ran tests. Did some basic testing. Seems to work fine.
>
> Regards
> Ram
>
> On Sat, Aug 13, 2016 at 9:44 AM, > wrote:
>
> > +1 (binding)
> >
> > - Built from source- loaded 100m rows via Phoenix- exercised flushes,
> > compactions, scans, etc.- nothing undue in the logs
> >
> > -- Lars
> >
> >   From: Andrew Purtell >
> >  To: "dev@hbase.apache.org "  >
> >  Sent: Monday, August 8, 2016 8:45 PM
> >  Subject: [VOTE] The 2nd HBase 0.98.21 release candidate (RC1) is
> available
> >
> > ​​The 2nd HBase 0.98.21 release candidate (RC1) is available for download
> > at https://dist.apache.org/repos/dist/dev/hbase/hbase-0.98.21RC1/ and
> > Maven
> > artifacts are also available in the temporary repository
> > https://repository.apache.org/content/repositories/orgapachehbase-1145/
> .
> >
> > The detailed source and binary compatibility report for this release with
> > respect to the previous is available for your review at
> > https://dist.apache.org/repos/dist/dev/hbase/hbase-0.98.
> > 21RC1/HBase_0.98.20_to_0.98.21RC1_compatibility_report.html
> > . There is one change of note: an allowable change to Public/Evolving
> > HFilePrettyPrinter introduced as part of a security fix.
> >
> > The 57 issues resolved in this release can be found at
> > https://s.apache.org/SfDQ .
> >
> > I have made the following assessments of this candidate:
> > - Release audit check passes
> > - Unit test suite passes (7u79)
> > - Loaded 1M keys with LTT (10 readers, 10 writers, 10 updaters (20%): all
> > keys verified, no unusual messages or errors, latencies in the ballpark
> > - IntegrationTestBigLinkedList writing 500M keys with slowDeterministic
> > chaos policy in effect: result is 100% referenced, no verification errors
> > (8u91)
> > - Built head of Apache Phoenix 4.x-HBase-0.98 branch, looks good (7u79)
> >
> > Signed with my code signing key D5365CCD.
> >
> > Please try out the candidate and vote +1/0/-1. This vote will be open for
> > at least 72 hours. Unless objection I will try to close it Monday August
> > 15, 2016 if we have sufficient votes.
> >
> > --
> > Best regards,
> >
> >   - Andy
> >
> > Problems worthy of attack prove their worth by hitting back. - Piet Hein
> > (via Tom White)
> >
> >
> >
>


-- 
-Dima

Someone please review HBASE-16318

[Sean Busbey]

Could someone please review the latest version of this change:


https://issues.apache.org/jira/browse/HBASE-16318

It's the stop-gap to make sure we don't accidentally include dependencies
with prohibited licenses again. It took me a long time to get done and it's
sat without comment for nearly a week.

-- 
busbey

[jira] [Created] (HBASE-16417) In-Memory MemStore Policy for Flattening and Compactions

[Anastasia Braginsky (JIRA)]

Anastasia Braginsky created HBASE-16417:
---

 Summary: In-Memory MemStore Policy for Flattening and Compactions
 Key: HBASE-16417
 URL: https://issues.apache.org/jira/browse/HBASE-16417
 Project: HBase
  Issue Type: Improvement
Reporter: Anastasia Braginsky






--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Created] (HBASE-16416) Make NoncedRegionServerCallable extends RegionServerCallable

[Guanghao Zhang (JIRA)]

Guanghao Zhang created HBASE-16416:
--

 Summary: Make NoncedRegionServerCallable extends 
RegionServerCallable
 Key: HBASE-16416
 URL: https://issues.apache.org/jira/browse/HBASE-16416
 Project: HBase
  Issue Type: Improvement
  Components: Client
Affects Versions: 2.0.0
Reporter: Guanghao Zhang
Priority: Minor


After HBASE-16308, there are a new class NoncedRegionServerCallable which 
extends AbstractRegionServerCallable. But it have some duplicate methods with 
RegionServerCallable. So we can make NoncedRegionServerCallable extends 
RegionServerCallable.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Created] (HBASE-16415) Replication in different namepace

[Christian Guegi (JIRA)]

Christian Guegi created HBASE-16415:
---

 Summary: Replication in different namepace
 Key: HBASE-16415
 URL: https://issues.apache.org/jira/browse/HBASE-16415
 Project: HBase
  Issue Type: New Feature
  Components: Replication
Reporter: Christian Guegi


It would be nice to replicate tables from one namespace to another namespace.

Example:
Master cluster, namespace=default, table=bar
Slave cluster, namespace=dr, table=bar

Replication happens in class ReplicationSink:
  public void replicateEntries(List entries, final CellScanner cells, 
...){
...
TableName table = 
TableName.valueOf(entry.getKey().getTableName().toByteArray());
...
addToHashMultiMap(rowMap, table, clusterIds, m);
...
for (Entry, List>> entry : 
rowMap.entrySet()) {
  batch(entry.getKey(), entry.getValue().values());
}
   }




--
This message was sent by Atlassian JIRA
(v6.3.4#6332)