[jira] [Resolved] (HBASE-19085) Fix findbug EQ_OVERRIDING_EQUALS_NOT_SYMMETRIC warning

[stack (JIRA)]

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

stack resolved HBASE-19085.
---
Resolution: Duplicate

Thanks [~ram_krish] ... [~chia7712] already noticed this. Just committed an 
addendum ..

commit 43a8ac00158e92c3015af7753edd8e835dc6054b
Author: Michael Stack 
Date:   Tue Oct 24 22:40:30 2017 -0700

BASE-19074 Miscellaneous Observer cleanups; ADDEDNUM to fix FindBugs

> Fix findbug EQ_OVERRIDING_EQUALS_NOT_SYMMETRIC warning
> --
>
> Key: HBASE-19085
> URL: https://issues.apache.org/jira/browse/HBASE-19085
> Project: HBase
>  Issue Type: Bug
>Reporter: ramkrishna.s.vasudevan
>Assignee: ramkrishna.s.vasudevan
> Fix For: 2.0.0-alpha-4
>
>
> Seems the recent commits have introduced a findbug warning.
>   'org.apache.hadoop.hbase.regionserver.MemStoreSizing overrides equals 
> in MemStoreSize and may not be symmetric'.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Created] (HBASE-19085) Fix findbug EQ_OVERRIDING_EQUALS_NOT_SYMMETRIC warning

[ramkrishna.s.vasudevan (JIRA)]

ramkrishna.s.vasudevan created HBASE-19085:
--

 Summary: Fix findbug EQ_OVERRIDING_EQUALS_NOT_SYMMETRIC warning
 Key: HBASE-19085
 URL: https://issues.apache.org/jira/browse/HBASE-19085
 Project: HBase
  Issue Type: Bug
Reporter: ramkrishna.s.vasudevan
Assignee: ramkrishna.s.vasudevan
 Fix For: 2.0.0-alpha-4


Seems the recent commits have introduced a findbug warning.
'org.apache.hadoop.hbase.regionserver.MemStoreSizing overrides equals 
in MemStoreSize and may not be symmetric'.




--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

Re: [NOTICE] possible cause of recent poor build quality on builds.a.o

[Sean Busbey]

sure here's the hadoop thread:

https://s.apache.org/azOi

On Wed, Oct 25, 2017 at 12:20 AM, Chia-Ping Tsai  wrote:
> Could you share the reference to the  hdfs changes or discussion?
>
> On 2017-10-25 02:06, Sean Busbey  wrote:
>> hi folks!
>>
>> FYI, the Hadoop folks have identified that some recent changes to HDFS
>> have been eating all memory on hosts where their tests run. So that
>> might be the culprit in our recent spat of new odd looking surefire
>> failures.
>>
>> Yetus is working to add in some guard rails to keep Hadoop from doing
>> this in the future:
>>
>> https://issues.apache.org/jira/browse/YETUS-561
>>
>> Related, I have a temporary measure in place on our precommit runs
>> that grabs a bunch of machine information (cpus, memory, disks, etc).
>> If you look at build artifacts they'll be in a directory named
>> 'machine' under 'patchprocess'.
>>

Re: [NOTICE] possible cause of recent poor build quality on builds.a.o

[Chia-Ping Tsai]

Could you share the reference to the  hdfs changes or discussion?

On 2017-10-25 02:06, Sean Busbey  wrote: 
> hi folks!
> 
> FYI, the Hadoop folks have identified that some recent changes to HDFS
> have been eating all memory on hosts where their tests run. So that
> might be the culprit in our recent spat of new odd looking surefire
> failures.
> 
> Yetus is working to add in some guard rails to keep Hadoop from doing
> this in the future:
> 
> https://issues.apache.org/jira/browse/YETUS-561
> 
> Related, I have a temporary measure in place on our precommit runs
> that grabs a bunch of machine information (cpus, memory, disks, etc).
> If you look at build artifacts they'll be in a directory named
> 'machine' under 'patchprocess'.
> 

Re: [DISCUSSION] Removing the bypass semantic from the Coprocessor APIs

[Anoop John]

+1 for not allowing flush/compaction CPs to do bypass.  So which all
pre hooks to support bypass now?  Some mutations related only?  If u
have a list pls post.  Better to add in HBASE-18770 jira

-Anoop-

On Wed, Oct 25, 2017 at 10:23 AM, Stack  wrote:
> I made a start on HBASE-18770. It has edit of RegionObserver which denotes
> methods that support bypass (Unfortunately, because of the varied
> signatures, how bypass is signaled varies too). Would appreciate a
> once-over.
>
> of note, a CP cannot bypass flush. Speak up if you think otherwise (or you
> can think of a case where this needed). My rationale is CPs won't have
> enough insider knowledge to do memory accounting in a world of in-memory
> compactions, and on/offheap memory in our hosting process. What ye reckon?
>
> Coprocessors have always been able to adjust what gets compacted in any run
> and even skirt compaction altogether by returning an empty set of files to
> compact. This works as it ever did.
>
> Thanks,
> S
>
>
>
> On Tue, Oct 17, 2017 at 9:46 PM, Stack  wrote:
>
>> I was going to pick up on the bypass after HBASE-19007 lands, cleaning up
>> our exposure of Master/RegionServerServices to Coprocessors (HBASE-19007
>> was going bad for a good while but lots of contributors and good discussion
>> and now I think we have it). Shouldn't be too much longer.
>>
>> Its CP API so I was figuring it an alpha-4 item.
>>
>> St.Ack
>>
>> On Tue, Oct 17, 2017 at 6:56 PM, 张铎(Duo Zhang) 
>> wrote:
>>
>>> Fine. Let me change the title of HBASE-18770 and prepare a patch there.
>>>
>>> May still a week or two before alpha4 I think. The scan injection, and
>>> flush/compaction trigger/track API is still unstable...
>>>
>>> 2017-10-18 6:12 GMT+08:00 Josh Elser :
>>>
>>> > (catching up here)
>>> >
>>> > I'm glad to see you fine folks came to a conclusion around a
>>> reduced-scope
>>> > solution (correct me if I'm wrong). "Some" bypass mechanism would stay
>>> for
>>> > preXXX methods, and we'd remove it for the other methods? What exactly
>>> the
>>> > "bypass API" would be is up in the air, correct?
>>> >
>>> > Duo -- maybe you could put the "current plan" on HBASE-18770 since
>>> > discussion appears to have died down?
>>> >
>>> > I was originally lamenting yet another big, sweeping change to CPs when
>>> I
>>> > had expected alpha-4 to have already landed. But, let me play devil's
>>> > advocate: is this something we still think is critical to do in
>>> alpha-4? I
>>> > can respect wanting to get address all of these smells, but I'd be
>>> worry it
>>> > delays us further.
>>> >
>>> >
>>> > On 10/11/17 9:53 PM, 张铎(Duo Zhang) wrote:
>>> >
>>> >> Creating an exception is expensive so if it is not suggested to do it
>>> in a
>>> >> normal case. A common trick is to create a global exception instance,
>>> and
>>> >> always throw it to avoid creating every time but I think it is more
>>> >> friendly to just use a return value?
>>> >>
>>> >> And for me, the bypass after preXXX for normal region operations just
>>> >> equals to a 'cancel', which is very clear and easy to understand, so I
>>> >> think it is OK to add bypass support for them. And also for compaction
>>> and
>>> >> flush, it is OK to give CP users the ability to cancel the operation as
>>> >> the
>>> >> semantic is clear, although I'm not sure how CP users would use this
>>> >> feature.
>>> >>
>>> >> In general, I think we can provide bypass/cancel support in preXXX
>>> methods
>>> >> where it is the very beginning of an operation.
>>> >>
>>> >> Thanks.
>>> >>
>>> >> 2017-10-12 3:10 GMT+08:00 Andrew Purtell :
>>> >>
>>> >> On Phoenix Increment by-pass, an ornery item is that Phoenix wants to
>>> use
>>> 
>>> >>> its long encoding writing Increments. Not sure how we'd do that,
>>> >>> selectively.
>>> >>>
>>> >>> If we can handle the rest of the trouble that you observed:
>>> >>>
>>> >>> 1) Lack of recognition and identification of when the key value to
>>> >>> increment doesn't exist
>>> >>> 2) Lack of the ability to set the timestamp of the updated key value.
>>> >>>
>>> >>> then they might be able to make it work. Perhaps a conversion from
>>> HBase
>>> >>> native to Phoenix LONG encoding when processing results, in the
>>> wrapping
>>> >>> scanner, informed by schema metadata.
>>> >>>
>>> >>> Or if we are keeping the bypass semantic in select places but
>>> >>> implementing
>>> >>> it with something other than today's bypass() API (please) this would
>>> be
>>> >>> another candidate for where to keep it. Duo suggests keeping the
>>> semantic
>>> >>> in all of the basic RPC preXXX hooks for query and mutation. We could
>>> >>> redo
>>> >>> those APIs to skip normal processing based on a return value or
>>> exception
>>> >>> but otherwise drop bypass from all the others. It will clean up areas
>>> of
>>> >>> confusion, e.g. can I bypass splits or flushes or not? Or what about
>>> this
>>> >>> 

Re: [DISCUSSION] Removing the bypass semantic from the Coprocessor APIs

[Stack]

I made a start on HBASE-18770. It has edit of RegionObserver which denotes
methods that support bypass (Unfortunately, because of the varied
signatures, how bypass is signaled varies too). Would appreciate a
once-over.

of note, a CP cannot bypass flush. Speak up if you think otherwise (or you
can think of a case where this needed). My rationale is CPs won't have
enough insider knowledge to do memory accounting in a world of in-memory
compactions, and on/offheap memory in our hosting process. What ye reckon?

Coprocessors have always been able to adjust what gets compacted in any run
and even skirt compaction altogether by returning an empty set of files to
compact. This works as it ever did.

Thanks,
S



On Tue, Oct 17, 2017 at 9:46 PM, Stack  wrote:

> I was going to pick up on the bypass after HBASE-19007 lands, cleaning up
> our exposure of Master/RegionServerServices to Coprocessors (HBASE-19007
> was going bad for a good while but lots of contributors and good discussion
> and now I think we have it). Shouldn't be too much longer.
>
> Its CP API so I was figuring it an alpha-4 item.
>
> St.Ack
>
> On Tue, Oct 17, 2017 at 6:56 PM, 张铎(Duo Zhang) 
> wrote:
>
>> Fine. Let me change the title of HBASE-18770 and prepare a patch there.
>>
>> May still a week or two before alpha4 I think. The scan injection, and
>> flush/compaction trigger/track API is still unstable...
>>
>> 2017-10-18 6:12 GMT+08:00 Josh Elser :
>>
>> > (catching up here)
>> >
>> > I'm glad to see you fine folks came to a conclusion around a
>> reduced-scope
>> > solution (correct me if I'm wrong). "Some" bypass mechanism would stay
>> for
>> > preXXX methods, and we'd remove it for the other methods? What exactly
>> the
>> > "bypass API" would be is up in the air, correct?
>> >
>> > Duo -- maybe you could put the "current plan" on HBASE-18770 since
>> > discussion appears to have died down?
>> >
>> > I was originally lamenting yet another big, sweeping change to CPs when
>> I
>> > had expected alpha-4 to have already landed. But, let me play devil's
>> > advocate: is this something we still think is critical to do in
>> alpha-4? I
>> > can respect wanting to get address all of these smells, but I'd be
>> worry it
>> > delays us further.
>> >
>> >
>> > On 10/11/17 9:53 PM, 张铎(Duo Zhang) wrote:
>> >
>> >> Creating an exception is expensive so if it is not suggested to do it
>> in a
>> >> normal case. A common trick is to create a global exception instance,
>> and
>> >> always throw it to avoid creating every time but I think it is more
>> >> friendly to just use a return value?
>> >>
>> >> And for me, the bypass after preXXX for normal region operations just
>> >> equals to a 'cancel', which is very clear and easy to understand, so I
>> >> think it is OK to add bypass support for them. And also for compaction
>> and
>> >> flush, it is OK to give CP users the ability to cancel the operation as
>> >> the
>> >> semantic is clear, although I'm not sure how CP users would use this
>> >> feature.
>> >>
>> >> In general, I think we can provide bypass/cancel support in preXXX
>> methods
>> >> where it is the very beginning of an operation.
>> >>
>> >> Thanks.
>> >>
>> >> 2017-10-12 3:10 GMT+08:00 Andrew Purtell :
>> >>
>> >> On Phoenix Increment by-pass, an ornery item is that Phoenix wants to
>> use
>> 
>> >>> its long encoding writing Increments. Not sure how we'd do that,
>> >>> selectively.
>> >>>
>> >>> If we can handle the rest of the trouble that you observed:
>> >>>
>> >>> 1) Lack of recognition and identification of when the key value to
>> >>> increment doesn't exist
>> >>> 2) Lack of the ability to set the timestamp of the updated key value.
>> >>>
>> >>> then they might be able to make it work. Perhaps a conversion from
>> HBase
>> >>> native to Phoenix LONG encoding when processing results, in the
>> wrapping
>> >>> scanner, informed by schema metadata.
>> >>>
>> >>> Or if we are keeping the bypass semantic in select places but
>> >>> implementing
>> >>> it with something other than today's bypass() API (please) this would
>> be
>> >>> another candidate for where to keep it. Duo suggests keeping the
>> semantic
>> >>> in all of the basic RPC preXXX hooks for query and mutation. We could
>> >>> redo
>> >>> those APIs to skip normal processing based on a return value or
>> exception
>> >>> but otherwise drop bypass from all the others. It will clean up areas
>> of
>> >>> confusion, e.g. can I bypass splits or flushes or not? Or what about
>> this
>> >>> arcane hook in compaction? Or [insert some deep hook here]? The answer
>> >>> would be: only RPC hooks will early out, and only if you return this
>> >>> value,
>> >>> or throw that exception.
>> >>>
>> >>>
>> >>> On Wed, Oct 11, 2017 at 11:56 AM, Stack  wrote:
>> >>>
>> >>> The YARN Timeline Server has the FlowRunCoprocessor. It does bypass
>> when
>>  user does a Get returning 

[jira] [Resolved] (HBASE-16885) Deprecate public classes which are removed in 2.0

[Ted Yu (JIRA)]

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

Ted Yu resolved HBASE-16885.

Resolution: Won't Fix

There have been many changes in API, making this obsolete.

> Deprecate public classes which are removed in 2.0
> -
>
> Key: HBASE-16885
> URL: https://issues.apache.org/jira/browse/HBASE-16885
> Project: HBase
>  Issue Type: Bug
>Reporter: Ted Yu
> Attachments: phoenix-compile-against-2.0.txt
>
>
> I tried to compile master branch of Phoenix against 2.0-SNAPSHOT and observed 
> some compilation errors.
> /phoenix/phoenix-core/src/main/java/org/apache/hadoop/hbase/regionserver/LocalIndexStoreFileScanner.java:[31,54]
>  cannot find symbol
>   symbol:   class Reader
>   location: class org.apache.hadoop.hbase.regionserver.StoreFile
> /phoenix/phoenix-core/src/main/java/org/apache/phoenix/mapreduce/MultiHfileOutputFormat.java:[300,16]
>  cannot find symbol
>   symbol:   class Writer
>   location: class org.apache.hadoop.hbase.regionserver.StoreFile
> The above inner classes of StoreFile are marked public as of branch-1.
> We should deprecate them in 1.x release.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

Re: [DISCUSS] Merge FilterList Improvement - Branch HBASE-18410

[Josh Elser]

+1 IMO, go for it -- enough eyes have been had on the last little bit.

On 10/24/17 11:05 PM, stack wrote:

The boys are almost ready to merge. They were going to run a VOTE. I told
them not to bother. There is enough support behind the merge they don't
need a vote IMO. If you think otherwise, speak up.

Thanks,

St.Ack
P.S. Release note on HBASE-18410 will have summary of changes that come in
on the merge. Thanks.

On Sat, Oct 21, 2017 at 6:37 PM, stack  wrote:


+1 on merge then sorting out the mess. I want to include this stuff in
alpha 4.

Thanks,
S

On Oct 20, 2017 01:18, "OpenInx"  wrote:


Fine,  I opened jira HBASE-19057 for it.

On Fri, Oct 20, 2017 at 4:13 PM, Anoop John 
wrote:


+1 for opening an issue and handle the merge as part of that.
I did a review of the new classes for the FilterList impl..  Great
cleanup work.  Very easy to read and understand the code now..
Have few comments specially on FilterListWithOR.   If u can raise a
merge issue, can comment down that.  If needed can open up subtasks
can then handle.

-Anoop-

On Fri, Oct 20, 2017 at 12:01 PM, 张铎(Duo Zhang) 
wrote:

Open a issue to track the merging work? Let's do a rebase and more

testing

in that issue. And then come back and open a vote.

2017-10-20 11:48 GMT+08:00 OpenInx :


  I believe there are several UTs which we want them to be the

guard of

merging?
What is the situation of these UTs?

The UT is TestFilterListOnMini which make sure the filter list with

family

filter in it works fine,  it's enable in branch HBASE-18410 now .

see

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


Some of recent patches, such as HBASE-18368-HBASE-18410.v2.patch,

didn't get
proper QA run

All of the UT passed except one failed case , and this failed case is
unrelated.   see
https://builds.apache.org/job/PreCommit-HBASE-Build/9157/testReport/


This is a incompatible change for filter developer ?


Yes, I think so.




On Fri, Oct 20, 2017 at 9:37 AM, Guanghao Zhang 
wrote:


HBASE-18368-HBASE-18410.v2.patch got a proper QA
run: PreCommit-HBASE-Build/9157. And the failed ut is not related.

So

I

committed it to branch HBASE-18410...
HBASE-18368 changed the javadoc of NEXT_ROW. This is a incompatible

change

for filter developer?

2017-10-20 9:14 GMT+08:00 Ted Yu :


Some of recent patches, such as HBASE-18368-HBASE-18410.v2.pat

ch,

didn't

get proper QA run (due to precommit disruption).

We'd better get several good QA runs.

Cheers

On Thu, Oct 19, 2017 at 5:38 PM, 张铎(Duo Zhang) <

palomino...@gmail.com>

wrote:


I believe there are several UTs which we want them to be the

guard of

merging? What is the situation of these UTs?

Thanks.

2017-10-20 8:33 GMT+08:00 OpenInx :


Hi All :


All subtasks have been resolved except HBASE-18993
, I think

it's

time

to

merge HBASE-18410 

Re: [DISCUSS] Merge hbase-metrics:oahh.metrics.impl into hbase-metrics-api

[Josh Elser]

Hey Appy,

I think Enis essentially copied what I was originally trying to do. Up 
in Avatica[1], I made a similar API Maven module which just had 
interfaces. The implementation was them split up into a different module 
to avoid the implementation details of the API (specifically, using 
Dropwizard3) from "infecting" anyone who just wanted the API. 
Implementations of the metrics API could be picked up via ServiceLoader.


So, here in HBase, our "hbase-metrics" module is really an 
implementation of hbase-metrics-api for dropwizard-metrics 3.2.1 (the 
naming just loses that detail).


In Avatica, I wanted to make sure that people could use a metrics 
library implementation of their choosing (e.g. tied to whatever kind of 
container or app-server you're deploying Avatica). In HBase, that isn't 
such a concern -- we publish via Metrics2 and that's it.


That said, I could see a place where this separation enables some extra 
functionality with less headache, but I, admittedly, don't have a 
concrete use-case behind it.


- Josh

[1] https://github.com/apache/calcite-avatica

On 10/24/17 6:09 PM, Apekshit Sharma wrote:

Hi

Am confused why do we have this weird circular dependency between the two
modules: hbase-metrics-api & hbase-metrics. And since maven doesn't allow
it explicitly, this was tucked and hidden by using reflection?

MetricRegistriesImpl[hbase-metrics] implements
MetricRegistries[hbase-metrics-api].
MetricRegistriesLoader[hbase-metrics-api] depends on this implementation,
MetricRegistriesImpl, because it instantiates it via reflection

[1].

Can we just move all interfaces and default implementation together into
single module. But i like the idea of keeping implementations in separate
package with "impl" explicitly in package name.

[1]
https://github.com/apache/hbase/blob/eee3b0180ead73c09b33f9583bfee9c01bc3aed2/hbase-metrics-api/src/main/java/org/apache/hadoop/hbase/metrics/MetricRegistriesLoader.java#L39

-- Appy

Re: [DISCUSS] Merge FilterList Improvement - Branch HBASE-18410

[stack]

The boys are almost ready to merge. They were going to run a VOTE. I told
them not to bother. There is enough support behind the merge they don't
need a vote IMO. If you think otherwise, speak up.

Thanks,

St.Ack
P.S. Release note on HBASE-18410 will have summary of changes that come in
on the merge. Thanks.

On Sat, Oct 21, 2017 at 6:37 PM, stack  wrote:

> +1 on merge then sorting out the mess. I want to include this stuff in
> alpha 4.
>
> Thanks,
> S
>
> On Oct 20, 2017 01:18, "OpenInx"  wrote:
>
>> Fine,  I opened jira HBASE-19057 for it.
>>
>> On Fri, Oct 20, 2017 at 4:13 PM, Anoop John 
>> wrote:
>>
>> > +1 for opening an issue and handle the merge as part of that.
>> > I did a review of the new classes for the FilterList impl..  Great
>> > cleanup work.  Very easy to read and understand the code now..
>> > Have few comments specially on FilterListWithOR.   If u can raise a
>> > merge issue, can comment down that.  If needed can open up subtasks
>> > can then handle.
>> >
>> > -Anoop-
>> >
>> > On Fri, Oct 20, 2017 at 12:01 PM, 张铎(Duo Zhang) 
>> > wrote:
>> > > Open a issue to track the merging work? Let's do a rebase and more
>> > testing
>> > > in that issue. And then come back and open a vote.
>> > >
>> > > 2017-10-20 11:48 GMT+08:00 OpenInx :
>> > >
>> > >> >  I believe there are several UTs which we want them to be the
>> guard of
>> > >> merging?
>> > >> What is the situation of these UTs?
>> > >>
>> > >> The UT is TestFilterListOnMini which make sure the filter list with
>> > family
>> > >> filter in it works fine,  it's enable in branch HBASE-18410 now .
>> see
>> > >> https://issues.apache.org/jira/browse/HBASE-18977.
>> > >>
>> > >> > Some of recent patches, such as HBASE-18368-HBASE-18410.v2.patch,
>> > >> didn't get
>> > >> proper QA run
>> > >>
>> > >> All of the UT passed except one failed case , and this failed case is
>> > >> unrelated.   see
>> > >> https://builds.apache.org/job/PreCommit-HBASE-Build/9157/testReport/
>> > >>
>> > >> > This is a incompatible change for filter developer ?
>> > >>
>> > >> Yes, I think so.
>> > >>
>> > >>
>> > >>
>> > >>
>> > >> On Fri, Oct 20, 2017 at 9:37 AM, Guanghao Zhang 
>> > >> wrote:
>> > >>
>> > >> > HBASE-18368-HBASE-18410.v2.patch got a proper QA
>> > >> > run: PreCommit-HBASE-Build/9157. And the failed ut is not related.
>> So
>> > I
>> > >> > committed it to branch HBASE-18410...
>> > >> > HBASE-18368 changed the javadoc of NEXT_ROW. This is a incompatible
>> > >> change
>> > >> > for filter developer?
>> > >> >
>> > >> > 2017-10-20 9:14 GMT+08:00 Ted Yu :
>> > >> >
>> > >> > > Some of recent patches, such as HBASE-18368-HBASE-18410.v2.pat
>> ch,
>> > >> didn't
>> > >> > > get proper QA run (due to precommit disruption).
>> > >> > >
>> > >> > > We'd better get several good QA runs.
>> > >> > >
>> > >> > > Cheers
>> > >> > >
>> > >> > > On Thu, Oct 19, 2017 at 5:38 PM, 张铎(Duo Zhang) <
>> > palomino...@gmail.com>
>> > >> > > wrote:
>> > >> > >
>> > >> > > > I believe there are several UTs which we want them to be the
>> > guard of
>> > >> > > > merging? What is the situation of these UTs?
>> > >> > > >
>> > >> > > > Thanks.
>> > >> > > >
>> > >> > > > 2017-10-20 8:33 GMT+08:00 OpenInx :
>> > >> > > >
>> > >> > > > > Hi All :
>> > >> > > > >
>> > >> > > > >
>> > >> > > > > All subtasks have been resolved except HBASE-18993
>> > >> > > > > , I think
>> > it's
>> > >> > time
>> > >> > > > to
>> > >> > > > > merge HBASE-18410 > > >> jira/browse/HBASE-18410
>> > >> > >
>> > >> > > > > branch
>> > >> > > > > to master now.
>> > >> > > > >
>> > >> > > > > Any concerns ?
>> > >> > > > >
>> > >> > > > > Thanks.
>> > >> > > > >
>> > >> > > >
>> > >> > >
>> > >> >
>> > >>
>> > >>
>> > >>
>> > >> --
>> > >> ==
>> > >> Openinx  blog : http://openinx.github.io
>> > >>
>> > >> TO BE A GREAT HACKER !
>> > >> ==
>> > >>
>> >
>>
>>
>>
>> --
>> ==
>> Openinx  blog : http://openinx.github.io
>>
>> TO BE A GREAT HACKER !
>> ==
>>
>

Re: [DISCUSS] Merge hbase-metrics:oahh.metrics.impl into hbase-metrics-api

[Apekshit Sharma]

Hey Elliott, good to see you around :)

Btw, this is new stuff added in HBASE-9774 which was committed to only 2.0.
Made it to 1.4 too later (HBASE-18060).

-- Appy

On Tue, Oct 24, 2017 at 4:16 PM, Elliott Clark  wrote:

> The weird module dance with reflection came from needing to extend inner
> hadoop classes on multiple different versions. This was back when HBase had
> to support hadoop < 1, hadoop 1.x, and hadoop 2.x. When we dropped older
> hadoop versions then things got easier.
>
> On Tue, Oct 24, 2017 at 3:09 PM, Apekshit Sharma 
> wrote:
>
> > Hi
> >
> > Am confused why do we have this weird circular dependency between the two
> > modules: hbase-metrics-api & hbase-metrics. And since maven doesn't allow
> > it explicitly, this was tucked and hidden by using reflection?
> >
> > MetricRegistriesImpl[hbase-metrics] implements
> > MetricRegistries[hbase-metrics-api].
> > MetricRegistriesLoader[hbase-metrics-api] depends on this
> implementation,
> > MetricRegistriesImpl, because it instantiates it via reflection
> >  > c01bc3aed2/hbase-metrics-api/src/main/java/org/apache/
> > hadoop/hbase/metrics/MetricRegistriesLoader.java#L39>
> > [1].
> >
> > Can we just move all interfaces and default implementation together into
> > single module. But i like the idea of keeping implementations in separate
> > package with "impl" explicitly in package name.
> >
> > [1]
> > https://github.com/apache/hbase/blob/eee3b0180ead73c09b33f9583bfee9
> > c01bc3aed2/hbase-metrics-api/src/main/java/org/apache/
> > hadoop/hbase/metrics/MetricRegistriesLoader.java#L39
> >
> > -- Appy
> >
>



-- 

-- Appy

Re: [DISCUSS] Merge hbase-metrics:oahh.metrics.impl into hbase-metrics-api

[Elliott Clark]

The weird module dance with reflection came from needing to extend inner
hadoop classes on multiple different versions. This was back when HBase had
to support hadoop < 1, hadoop 1.x, and hadoop 2.x. When we dropped older
hadoop versions then things got easier.

On Tue, Oct 24, 2017 at 3:09 PM, Apekshit Sharma  wrote:

> Hi
>
> Am confused why do we have this weird circular dependency between the two
> modules: hbase-metrics-api & hbase-metrics. And since maven doesn't allow
> it explicitly, this was tucked and hidden by using reflection?
>
> MetricRegistriesImpl[hbase-metrics] implements
> MetricRegistries[hbase-metrics-api].
> MetricRegistriesLoader[hbase-metrics-api] depends on this implementation,
> MetricRegistriesImpl, because it instantiates it via reflection
>  c01bc3aed2/hbase-metrics-api/src/main/java/org/apache/
> hadoop/hbase/metrics/MetricRegistriesLoader.java#L39>
> [1].
>
> Can we just move all interfaces and default implementation together into
> single module. But i like the idea of keeping implementations in separate
> package with "impl" explicitly in package name.
>
> [1]
> https://github.com/apache/hbase/blob/eee3b0180ead73c09b33f9583bfee9
> c01bc3aed2/hbase-metrics-api/src/main/java/org/apache/
> hadoop/hbase/metrics/MetricRegistriesLoader.java#L39
>
> -- Appy
>

Re: Moving 2.0 forward

[Stack]

Chatting with my coworker Mr. Mike Drob, we were batting back and forth
what remains to be done. Surfacing our thoughts here so you all clued
inOr if you think otherwise, please speak up.

We have ~13 issues to land:
https://issues.apache.org/jira/projects/HBASE/versions/12341594 About two
are meta-issues that are about process which leaves 11.

Duo and Zheng Hu are to merge the FilterList fixes improvements
(HBASE-19057, HBASE-18410 et al.). These are blocker because some changed
API/semantic that we need to get out earlier rather than later.

Once the above is merged, HBASE-13346, change of Filter method names to
mention Cell instead of KeyValue can land.

HBASE-199048 needs a review (Anoop will probably do it), removing
IA.Private objects as params to MasterObserver... Hopefully this goes in
soon.

Duo is hard at work on trackers for flush and compaction for CPs
(HBASE-18905). How is HBASE-19033 looking Duo (facility for Tephra)?

I think HBASE-18906 (Phoenix Region#waitFor...) will evaporate after Duo is
done w/ his work above.

I'm on HBASE-18770 bypass and HBASE-19077 restore some parity after all the
purges allowing CPs do direct calls against Regions in same Host.

Anoop is on HBASE-19047 (Fixes) and Ram on cleanup of CellUtil.

Another day or two?

St.Ack



On Mon, Oct 23, 2017 at 2:52 PM, Stack  wrote:

>
> On Mon, Oct 23, 2017 at 11:59 AM, Josh Elser  wrote:
>
>> +1
>>
>> I was trying to work on helping out on the outstanding alpha-4 stuff last
>> week -- will be continuing to try to do the same this week.
>>
>> If you need any help, Stack, or if others need reviews where I haven't
>> noticed on my own: feel free to @mention me.
>>
>>
> Thanks for the offer Josh. All items seem assigned and are being actively
> worked on. If you get a moment, reviews by you (or anyone else) helps move
> the process along.
>
> We need to merge in HBASE-18410 branch to pick up Filter improvements.
> Then HBASE-13346 can go in.
>
> You are already helping out on HBASE-18906, thanks. Looks like that will
> be addressed by other alpha-4s about to land.
>
> St.Ack
> TODOs: https://issues.apache.org/jira/projects/HBASE/versions/12341594
>
>
>
>
>
>
>
>
>
>> On 10/23/17 12:53 PM, Stack wrote:
>>
>>> (Reviving this thread)
>>>
>>> Lets push out alpha-4 this week. Alpha-4 is the release that has the
>>> refactor of the Coprocessor API shutting down access to internals marked
>>> InterfaceAudience.Private.
>>>
>>> The outstanding list is here:
>>> https://issues.apache.org/jira/projects/HBASE/versions/12341594
>>>
>>> Please push in anything marked alpha-4 that belongs to you.
>>>
>>> If issue, talk out loud on this thread. If you need a review to land an
>>> item, shout on the issue and here; we'll help you out.
>>>
>>> As is, items are coming along nicely I'd say. We need to merge the filter
>>> branch -- HBASE-18410 -- so APIs are finished for hbase2.
>>>
>>> Post alpha-4, we'll have to hunt down our downstreamers and help them
>>> test
>>> on top of alpha-4 so rolling into beta-1, we have confidence our
>>> downstreamers know what to expect (or we discover what we missed BEFORE
>>> we
>>> beta-1).
>>>
>>> Thanks for time,
>>> S
>>>
>>>
>>>
>>>
>>>
>>> On Fri, Sep 8, 2017 at 2:04 PM, Stack  wrote:
>>>
>>> I'll put up an alpha3 RC Monday, probably Monday night. That should be
 time, if we all sprint, for the public-facing API fixes to be done.

 I had a bunch of Coprocessor refactor and fixup scheduled for alpha3 but
 it is plain that more time is needed (in spite of valiant effort so far
 by
 Anoop, Duo, Appy, etc.). Therefore, lets run a 2.0.0-alpha-4 whose
 theme is
 "Coprocessor Fixup". Hopefully we can put an alpha-4 up by the following
 week.

 We should then be ready for beta (beta == no new features, no API
 changes,
 just fixes).

 Thanks,
 St.Ack


 On Thu, Aug 17, 2017 at 12:35 PM, Stack  wrote:

 I put up the hbase-2.0.0-alpha2 release candidate. Please vote on it.
>
> For hbase-2.0.0-alpha3, the theme is solidifying API. I hope to get a
> release out in the next week or so.
>
> I did a weeding of 2.0.0 issues over the last day. If folks are
> interested in helping out, below are the items I think we need done for
> alpha3 (below are at least 'Critical' status, are API possibly altering
> items, and are absent those JIRAs that are making active progress,
> i.e. the
> HTD/HCD revamp by Chia-Ping Tsai). A project NOT listed that needs
> doing is
> what Andrew did comparing 1.3. and 1.4 APIs
>
> * HBASE-18622 Mitigate compatibility concerns between branch-1 and
> branch-2
> This is to do what Andrew did between 1.3 and 1.4 branches only do it
> between branch-1 and branch-2.
>
> * HBASE-10462 Recategorize some of the client facing Public / Private
> interfaces
> This 

[NOTICE] possible cause of recent poor build quality on builds.a.o

[Sean Busbey]

hi folks!

FYI, the Hadoop folks have identified that some recent changes to HDFS
have been eating all memory on hosts where their tests run. So that
might be the culprit in our recent spat of new odd looking surefire
failures.

Yetus is working to add in some guard rails to keep Hadoop from doing
this in the future:

https://issues.apache.org/jira/browse/YETUS-561

Related, I have a temporary measure in place on our precommit runs
that grabs a bunch of machine information (cpus, memory, disks, etc).
If you look at build artifacts they'll be in a directory named
'machine' under 'patchprocess'.

[jira] [Resolved] (HBASE-19049) Update kerby to 1.0.1 GA release

[Sean Busbey (JIRA)]

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

Sean Busbey resolved HBASE-19049.
-
  Resolution: Fixed
Release Note: HBase now relies on Kerby version 1.0.1 for its test 
environment. No downstream facing change is expected.

> Update kerby to 1.0.1 GA release
> 
>
> Key: HBASE-19049
> URL: https://issues.apache.org/jira/browse/HBASE-19049
> Project: HBase
>  Issue Type: Task
>  Components: dependencies
>Affects Versions: 2.0.0-alpha-3
>Reporter: Sean Busbey
>Assignee: Sean Busbey
> Fix For: 3.0.0, 2.0.0-alpha-4
>
> Attachments: HBASE-19049.0.patch, HBASE-19049.1.patch
>
>
> Hadoop 3.0.0-alpha4+ has moved to kerby 1.0.0 GA, so our tests that use their 
> minikdc fail with a version mismatch because we still declare 1.0.0-RC2



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Reopened] (HBASE-19049) Update kerby to 1.0.1 GA release

[Sean Busbey (JIRA)]

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

Sean Busbey reopened HBASE-19049:
-

> Update kerby to 1.0.1 GA release
> 
>
> Key: HBASE-19049
> URL: https://issues.apache.org/jira/browse/HBASE-19049
> Project: HBase
>  Issue Type: Task
>  Components: dependencies
>Affects Versions: 2.0.0-alpha-3
>Reporter: Sean Busbey
>Assignee: Sean Busbey
> Fix For: 3.0.0, 2.0.0-alpha-4
>
> Attachments: HBASE-19049.0.patch, HBASE-19049.1.patch
>
>
> Hadoop 3.0.0-alpha4+ has moved to kerby 1.0.0 GA, so our tests that use their 
> minikdc fail with a version mismatch because we still declare 1.0.0-RC2



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Created] (HBASE-19084) precommit should have a check for commit id in the commit message

[Mike Drob (JIRA)]

Mike Drob created HBASE-19084:
-

 Summary: precommit should have a check for commit id in the commit 
message
 Key: HBASE-19084
 URL: https://issues.apache.org/jira/browse/HBASE-19084
 Project: HBase
  Issue Type: Improvement
  Components: build, community
Reporter: Mike Drob
Priority: Critical


We should have a precommit check that examines patches for a Change-Id line and 
votes against them.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

Re: [ANNOUNCE] New HBase committer Zheng Hu

[Srinivas Reddy]

Congratulations Zheng!!



--
Srinivas Reddy

http://mrsrinivas.com/


(Sent via gmail web)

On 24 October 2017 at 16:23, Abhishek Singh Chouhan <
abhishekchouhan...@gmail.com> wrote:

> Congrats Zheng!!
>
> On Tue, Oct 24, 2017 at 3:43 PM, Yu Li  wrote:
>
> > Congratulations and welcome!
> >
> > Best Regards,
> > Yu
> >
> > On 24 October 2017 at 14:59, Misty Stanley-Jones 
> wrote:
> >
> > > Welcome Zheng Hu and thanks for your contributions to the project!
> > >
> > > On Sun, Oct 22, 2017 at 11:18 PM Duo Zhang 
> wrote:
> > >
> > > > On behalf of the Apache HBase PMC, I am pleased to announce that
> Zheng
> > Hu
> > > > has accepted the PMC's invitation to become a committer on the
> project.
> > > We
> > > > appreciate all of Zheng's generous contributions thus far and look
> > > forward
> > > > to his continued involvement.
> > > >
> > > > Congratulations and welcome, Zheng!
> > > >
> > >
> >
>

Re: [ANNOUNCE] New HBase committer Zheng Hu

[Abhishek Singh Chouhan]

Congrats Zheng!!

On Tue, Oct 24, 2017 at 3:43 PM, Yu Li  wrote:

> Congratulations and welcome!
>
> Best Regards,
> Yu
>
> On 24 October 2017 at 14:59, Misty Stanley-Jones  wrote:
>
> > Welcome Zheng Hu and thanks for your contributions to the project!
> >
> > On Sun, Oct 22, 2017 at 11:18 PM Duo Zhang  wrote:
> >
> > > On behalf of the Apache HBase PMC, I am pleased to announce that Zheng
> Hu
> > > has accepted the PMC's invitation to become a committer on the project.
> > We
> > > appreciate all of Zheng's generous contributions thus far and look
> > forward
> > > to his continued involvement.
> > >
> > > Congratulations and welcome, Zheng!
> > >
> >
>

Re: [ANNOUNCE] New HBase committer Zheng Hu

[Yu Li]

Congratulations and welcome!

Best Regards,
Yu

On 24 October 2017 at 14:59, Misty Stanley-Jones  wrote:

> Welcome Zheng Hu and thanks for your contributions to the project!
>
> On Sun, Oct 22, 2017 at 11:18 PM Duo Zhang  wrote:
>
> > On behalf of the Apache HBase PMC, I am pleased to announce that Zheng Hu
> > has accepted the PMC's invitation to become a committer on the project.
> We
> > appreciate all of Zheng's generous contributions thus far and look
> forward
> > to his continued involvement.
> >
> > Congratulations and welcome, Zheng!
> >
>

[jira] [Created] (HBASE-19083) Introduce a new log writer which can write to two HDFSes

[Duo Zhang (JIRA)]

Duo Zhang created HBASE-19083:
-

 Summary: Introduce a new log writer which can write to two HDFSes
 Key: HBASE-19083
 URL: https://issues.apache.org/jira/browse/HBASE-19083
 Project: HBase
  Issue Type: Sub-task
  Components: Replication, wal
Reporter: Duo Zhang






--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Created] (HBASE-19081) Implement a procedure to convert RS from S to DA

[Duo Zhang (JIRA)]

Duo Zhang created HBASE-19081:
-

 Summary: Implement a procedure to convert RS from S to DA
 Key: HBASE-19081
 URL: https://issues.apache.org/jira/browse/HBASE-19081
 Project: HBase
  Issue Type: Sub-task
Reporter: Duo Zhang






--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Created] (HBASE-19082) Implement a procedure to convert RS from DA to S

[Duo Zhang (JIRA)]

Duo Zhang created HBASE-19082:
-

 Summary: Implement a procedure to convert RS from DA to S
 Key: HBASE-19082
 URL: https://issues.apache.org/jira/browse/HBASE-19082
 Project: HBase
  Issue Type: Sub-task
Reporter: Duo Zhang






--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Created] (HBASE-19080) Implement a procedure to convert RS from A to DA

[Duo Zhang (JIRA)]

Duo Zhang created HBASE-19080:
-

 Summary: Implement a procedure to convert RS from A to DA
 Key: HBASE-19080
 URL: https://issues.apache.org/jira/browse/HBASE-19080
 Project: HBase
  Issue Type: Sub-task
Reporter: Duo Zhang






--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Created] (HBASE-19079) Implement a procedure to convert normal RS to state DA

[Duo Zhang (JIRA)]

Duo Zhang created HBASE-19079:
-

 Summary: Implement a procedure to convert normal RS to state DA
 Key: HBASE-19079
 URL: https://issues.apache.org/jira/browse/HBASE-19079
 Project: HBase
  Issue Type: Sub-task
Reporter: Duo Zhang






--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Created] (HBASE-19078) Introduce a new replication peer type for synchronous replication

[Duo Zhang (JIRA)]

Duo Zhang created HBASE-19078:
-

 Summary: Introduce a new replication peer type for synchronous 
replication
 Key: HBASE-19078
 URL: https://issues.apache.org/jira/browse/HBASE-19078
 Project: HBase
  Issue Type: Sub-task
Reporter: Duo Zhang






--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Resolved] (HBASE-18751) Revisit the TimeRange and TimeRangeTracker

[Chia-Ping Tsai (JIRA)]

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

Chia-Ping Tsai resolved HBASE-18751.

Resolution: Fixed

> Revisit the TimeRange and TimeRangeTracker
> --
>
> Key: HBASE-18751
> URL: https://issues.apache.org/jira/browse/HBASE-18751
> Project: HBase
>  Issue Type: Umbrella
>Reporter: Chia-Ping Tsai
>Assignee: Chia-Ping Tsai
> Fix For: 2.0.0-beta-1
>
>




--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

Re: Moving 2.0 forward

[ramkrishna vasudevan]

Thanks Stack. Started working on it. Will post a patch ASAP.

On Tue, Oct 24, 2017 at 11:38 AM, Stack  wrote:

> That'd be a good one to get in Ram.
> S
>
> On Mon, Oct 23, 2017 at 9:42 PM, ramkrishna vasudevan <
> ramkrishna.s.vasude...@gmail.com> wrote:
>
> > Hi Stack
> >
> > Do you want HBASE-18995 before the alpha-4 (REmoving exposed internal
> APIs
> > from CellUtil)? Because you had mentioned no more API changes. If so I
> will
> > start making changes and put up a patch ASAP.
> >
> > Regards
> > Ram
> >
> > On Tue, Oct 24, 2017 at 3:22 AM, Stack  wrote:
> >
> > > On Mon, Oct 23, 2017 at 11:59 AM, Josh Elser 
> wrote:
> > >
> > > > +1
> > > >
> > > > I was trying to work on helping out on the outstanding alpha-4 stuff
> > last
> > > > week -- will be continuing to try to do the same this week.
> > > >
> > > > If you need any help, Stack, or if others need reviews where I
> haven't
> > > > noticed on my own: feel free to @mention me.
> > > >
> > > >
> > > Thanks for the offer Josh. All items seem assigned and are being
> actively
> > > worked on. If you get a moment, reviews by you (or anyone else) helps
> > move
> > > the process along.
> > >
> > > We need to merge in HBASE-18410 branch to pick up Filter improvements.
> > Then
> > > HBASE-13346 can go in.
> > >
> > > You are already helping out on HBASE-18906, thanks. Looks like that
> will
> > be
> > > addressed by other alpha-4s about to land.
> > >
> > > St.Ack
> > > TODOs: https://issues.apache.org/jira/projects/HBASE/versions/12341594
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > > > On 10/23/17 12:53 PM, Stack wrote:
> > > >
> > > >> (Reviving this thread)
> > > >>
> > > >> Lets push out alpha-4 this week. Alpha-4 is the release that has the
> > > >> refactor of the Coprocessor API shutting down access to internals
> > marked
> > > >> InterfaceAudience.Private.
> > > >>
> > > >> The outstanding list is here:
> > > >> https://issues.apache.org/jira/projects/HBASE/versions/12341594
> > > >>
> > > >> Please push in anything marked alpha-4 that belongs to you.
> > > >>
> > > >> If issue, talk out loud on this thread. If you need a review to land
> > an
> > > >> item, shout on the issue and here; we'll help you out.
> > > >>
> > > >> As is, items are coming along nicely I'd say. We need to merge the
> > > filter
> > > >> branch -- HBASE-18410 -- so APIs are finished for hbase2.
> > > >>
> > > >> Post alpha-4, we'll have to hunt down our downstreamers and help
> them
> > > test
> > > >> on top of alpha-4 so rolling into beta-1, we have confidence our
> > > >> downstreamers know what to expect (or we discover what we missed
> > BEFORE
> > > we
> > > >> beta-1).
> > > >>
> > > >> Thanks for time,
> > > >> S
> > > >>
> > > >>
> > > >>
> > > >>
> > > >>
> > > >> On Fri, Sep 8, 2017 at 2:04 PM, Stack  wrote:
> > > >>
> > > >> I'll put up an alpha3 RC Monday, probably Monday night. That should
> be
> > > >>> time, if we all sprint, for the public-facing API fixes to be done.
> > > >>>
> > > >>> I had a bunch of Coprocessor refactor and fixup scheduled for
> alpha3
> > > but
> > > >>> it is plain that more time is needed (in spite of valiant effort so
> > far
> > > >>> by
> > > >>> Anoop, Duo, Appy, etc.). Therefore, lets run a 2.0.0-alpha-4 whose
> > > theme
> > > >>> is
> > > >>> "Coprocessor Fixup". Hopefully we can put an alpha-4 up by the
> > > following
> > > >>> week.
> > > >>>
> > > >>> We should then be ready for beta (beta == no new features, no API
> > > >>> changes,
> > > >>> just fixes).
> > > >>>
> > > >>> Thanks,
> > > >>> St.Ack
> > > >>>
> > > >>>
> > > >>> On Thu, Aug 17, 2017 at 12:35 PM, Stack  wrote:
> > > >>>
> > > >>> I put up the hbase-2.0.0-alpha2 release candidate. Please vote on
> it.
> > > 
> > >  For hbase-2.0.0-alpha3, the theme is solidifying API. I hope to
> get
> > a
> > >  release out in the next week or so.
> > > 
> > >  I did a weeding of 2.0.0 issues over the last day. If folks are
> > >  interested in helping out, below are the items I think we need
> done
> > > for
> > >  alpha3 (below are at least 'Critical' status, are API possibly
> > > altering
> > >  items, and are absent those JIRAs that are making active progress,
> > > i.e.
> > >  the
> > >  HTD/HCD revamp by Chia-Ping Tsai). A project NOT listed that needs
> > >  doing is
> > >  what Andrew did comparing 1.3. and 1.4 APIs
> > > 
> > >  * HBASE-18622 Mitigate compatibility concerns between branch-1 and
> > >  branch-2
> > >  This is to do what Andrew did between 1.3 and 1.4 branches only do
> > it
> > >  between branch-1 and branch-2.
> > > 
> > >  * HBASE-10462 Recategorize some of the client facing Public /
> > Private
> > >  interfaces
> > >  This one is almost done. It could do with a finish, attention to
> the
> > >  items in last comment, and then our codebase could 

Re: [ANNOUNCE] New HBase committer Zheng Hu

[Misty Stanley-Jones]

Welcome Zheng Hu and thanks for your contributions to the project!

On Sun, Oct 22, 2017 at 11:18 PM Duo Zhang  wrote:

> On behalf of the Apache HBase PMC, I am pleased to announce that Zheng Hu
> has accepted the PMC's invitation to become a committer on the project. We
> appreciate all of Zheng's generous contributions thus far and look forward
> to his continued involvement.
>
> Congratulations and welcome, Zheng!
>

[jira] [Created] (HBASE-19077) Have Region*CoprocessorEnvironment provide an ImmutableOnlineRegions

[stack (JIRA)]

stack created HBASE-19077:
-

 Summary: Have Region*CoprocessorEnvironment provide an 
ImmutableOnlineRegions
 Key: HBASE-19077
 URL: https://issues.apache.org/jira/browse/HBASE-19077
 Project: HBase
  Issue Type: Bug
  Components: Coprocessors
Reporter: stack
Assignee: stack
Priority: Critical
 Fix For: 2.0.0-alpha-4


This is about restoring some of the hbase1 parity... You used to be able to get 
list of Region on the local server and talk to them directly.

Suggested by [~anoop.hbase] up in review. Makes sense.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

Re: Moving 2.0 forward

[Stack]

That'd be a good one to get in Ram.
S

On Mon, Oct 23, 2017 at 9:42 PM, ramkrishna vasudevan <
ramkrishna.s.vasude...@gmail.com> wrote:

> Hi Stack
>
> Do you want HBASE-18995 before the alpha-4 (REmoving exposed internal APIs
> from CellUtil)? Because you had mentioned no more API changes. If so I will
> start making changes and put up a patch ASAP.
>
> Regards
> Ram
>
> On Tue, Oct 24, 2017 at 3:22 AM, Stack  wrote:
>
> > On Mon, Oct 23, 2017 at 11:59 AM, Josh Elser  wrote:
> >
> > > +1
> > >
> > > I was trying to work on helping out on the outstanding alpha-4 stuff
> last
> > > week -- will be continuing to try to do the same this week.
> > >
> > > If you need any help, Stack, or if others need reviews where I haven't
> > > noticed on my own: feel free to @mention me.
> > >
> > >
> > Thanks for the offer Josh. All items seem assigned and are being actively
> > worked on. If you get a moment, reviews by you (or anyone else) helps
> move
> > the process along.
> >
> > We need to merge in HBASE-18410 branch to pick up Filter improvements.
> Then
> > HBASE-13346 can go in.
> >
> > You are already helping out on HBASE-18906, thanks. Looks like that will
> be
> > addressed by other alpha-4s about to land.
> >
> > St.Ack
> > TODOs: https://issues.apache.org/jira/projects/HBASE/versions/12341594
> >
> >
> >
> >
> >
> >
> >
> >
> >
> > > On 10/23/17 12:53 PM, Stack wrote:
> > >
> > >> (Reviving this thread)
> > >>
> > >> Lets push out alpha-4 this week. Alpha-4 is the release that has the
> > >> refactor of the Coprocessor API shutting down access to internals
> marked
> > >> InterfaceAudience.Private.
> > >>
> > >> The outstanding list is here:
> > >> https://issues.apache.org/jira/projects/HBASE/versions/12341594
> > >>
> > >> Please push in anything marked alpha-4 that belongs to you.
> > >>
> > >> If issue, talk out loud on this thread. If you need a review to land
> an
> > >> item, shout on the issue and here; we'll help you out.
> > >>
> > >> As is, items are coming along nicely I'd say. We need to merge the
> > filter
> > >> branch -- HBASE-18410 -- so APIs are finished for hbase2.
> > >>
> > >> Post alpha-4, we'll have to hunt down our downstreamers and help them
> > test
> > >> on top of alpha-4 so rolling into beta-1, we have confidence our
> > >> downstreamers know what to expect (or we discover what we missed
> BEFORE
> > we
> > >> beta-1).
> > >>
> > >> Thanks for time,
> > >> S
> > >>
> > >>
> > >>
> > >>
> > >>
> > >> On Fri, Sep 8, 2017 at 2:04 PM, Stack  wrote:
> > >>
> > >> I'll put up an alpha3 RC Monday, probably Monday night. That should be
> > >>> time, if we all sprint, for the public-facing API fixes to be done.
> > >>>
> > >>> I had a bunch of Coprocessor refactor and fixup scheduled for alpha3
> > but
> > >>> it is plain that more time is needed (in spite of valiant effort so
> far
> > >>> by
> > >>> Anoop, Duo, Appy, etc.). Therefore, lets run a 2.0.0-alpha-4 whose
> > theme
> > >>> is
> > >>> "Coprocessor Fixup". Hopefully we can put an alpha-4 up by the
> > following
> > >>> week.
> > >>>
> > >>> We should then be ready for beta (beta == no new features, no API
> > >>> changes,
> > >>> just fixes).
> > >>>
> > >>> Thanks,
> > >>> St.Ack
> > >>>
> > >>>
> > >>> On Thu, Aug 17, 2017 at 12:35 PM, Stack  wrote:
> > >>>
> > >>> I put up the hbase-2.0.0-alpha2 release candidate. Please vote on it.
> > 
> >  For hbase-2.0.0-alpha3, the theme is solidifying API. I hope to get
> a
> >  release out in the next week or so.
> > 
> >  I did a weeding of 2.0.0 issues over the last day. If folks are
> >  interested in helping out, below are the items I think we need done
> > for
> >  alpha3 (below are at least 'Critical' status, are API possibly
> > altering
> >  items, and are absent those JIRAs that are making active progress,
> > i.e.
> >  the
> >  HTD/HCD revamp by Chia-Ping Tsai). A project NOT listed that needs
> >  doing is
> >  what Andrew did comparing 1.3. and 1.4 APIs
> > 
> >  * HBASE-18622 Mitigate compatibility concerns between branch-1 and
> >  branch-2
> >  This is to do what Andrew did between 1.3 and 1.4 branches only do
> it
> >  between branch-1 and branch-2.
> > 
> >  * HBASE-10462 Recategorize some of the client facing Public /
> Private
> >  interfaces
> >  This one is almost done. It could do with a finish, attention to the
> >  items in last comment, and then our codebase could do with another
> > sweep
> >  after the spirit of this issue since a bunch has gone in since the
> > pass
> >  that was the basis of this issue.
> > 
> >  * HBASE-10504 Define Replication Interface
> >  I was going to take a crack at this as part of the revamp forced by
> >  'HBASE-15982 Interface ReplicationEndpoint extends Guava's Service'
> > but
> >  if
> >  anyone else is interested, be my guest.
> >