Re: [INFO] Failing Precommit Builds - HBASE-19042

[Stack]

On Thu, Oct 19, 2017 at 4:41 PM, Mike Drob  wrote:

> ...
> And huge thank you to Duo, Misty, Sean, and Peter for their parts to
> resolve the original issue. It is a great example of the community working
> together.
>
> I love it!
S




> Mike
>
> On Thu, Oct 19, 2017, 4:44 PM Mike Drob  wrote:
>
> > This issue should be resolved now. I went through and tried to manually
> > trigger a precommit on Jenkins for issues where I saw failed precommit
> > runs, but can't guarantee that I caught everything.
> >
> > We are now using openjdk-8 for our precommit runs. Please be vigilant for
> > things that you think might be subtle bugs due to switching JDK vendors
> and
> > report them. These should be rare, but have cropped up from time to time.
> >
> > Thanks,
> > Mike
> >
> > On Wed, Oct 18, 2017 at 8:57 PM, Sean Busbey 
> > wrote:
> >
> >> Thanks for the heads up and thanks to the folks digging in on this.
> >>
> >> Great find Peter!
> >>
> >> On Oct 18, 2017 8:52 PM, "Mike Drob"  wrote:
> >>
> >> > Hi devs,
> >> >
> >> > Wanted to send a quick note, since some of you have noticed our
> >> precommit
> >> > failing with mysterious docker errors.
> >> >
> >> > Our Peter has diagnosed this as Oracle changing their download URL
> when
> >> > releasing the latest update of Java 8. There's a few different
> proposed
> >> > solutions here, the final fix will be tracked in
> >> > https://issues.apache.org/jira/browse/HBASE-19042
> >> >
> >> > We understand that this is frustrating for folks trying to submit
> >> patches
> >> > currently, and appreciate your patience while waiting for a solution.
> If
> >> > you have questions, comments, concerns, or suggestions, please reply
> >> here
> >> > or on the JIRA.
> >> >
> >> > Thanks,
> >> > Mike
> >> >
> >>
> >
> >
>

[jira] [Created] (HBASE-19056) TestCompactionInDeadRegionServer is top of the flakies charts!

[stack (JIRA)]

stack created HBASE-19056:
-

 Summary:  TestCompactionInDeadRegionServer is top of the flakies 
charts!
 Key: HBASE-19056
 URL: https://issues.apache.org/jira/browse/HBASE-19056
 Project: HBase
  Issue Type: Bug
  Components: test
Reporter: stack


The test came in recently as part of HBASE-17712 "Remove/Simplify the logic of 
RegionScannerImpl.handleFileNotFound"

[~Apache9] when you have a chance, help me out. I was going to just remove the 
test since it made no sense to me but then I saw you wrote it  (smile).

When the region.compact(true); is called on the end, what is supposed to be 
going on?

When I trace, the compact is not done because the Region is not writeEnabled 
(we check if Region is writeEnabled down in Store before we go ahead and 
compact). So, I thought the problem was that the region reference was stale 
because it came from the rsToSuspend which had just been killed.

After a while, I figured that you intend the region reference to be stale so 
you can try an append AFTER the WAL has been taken over by WAL splitter.

But the writeEnabled flag is set so compactions don't run. I tried unsetting 
this flag and closed flags and but compaction won't run.

Was this your intent sir? If so, I'll work w/ it np. Just looking for clarity. 
Thanks. 



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

[jira] [Resolved] (HBASE-17369) Add ACL to the new region server drain related API

[Jerry He (JIRA)]

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

Jerry He resolved HBASE-17369.
--
Resolution: Implemented

Implemented as part of HBASE-10367.

> Add ACL to the new region server drain related API
> --
>
> Key: HBASE-17369
> URL: https://issues.apache.org/jira/browse/HBASE-17369
> Project: HBase
>  Issue Type: Sub-task
>Affects Versions: 2.0.0
>Reporter: Jerry He
>Priority: Critical
>
> Add ACL to the new region server drain related API.



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

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

[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.patch, 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) 
> > 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  >
> > > > branch
> > > > to master now.
> > > >
> > > > Any concerns ?
> > > >
> > > > Thanks.
> > > >
> > >
> >
>



-- 
==
Openinx  blog : http://openinx.github.io

TO BE A GREAT HACKER !
==

[jira] [Resolved] (HBASE-18249) Explicitly mark failed small test(s)

[Ted Yu (JIRA)]

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

Ted Yu resolved HBASE-18249.

Resolution: Later

> Explicitly mark failed small test(s)
> 
>
> Key: HBASE-18249
> URL: https://issues.apache.org/jira/browse/HBASE-18249
> Project: HBase
>  Issue Type: Test
>Reporter: Ted Yu
>
> In some cases, I would remind contributor to re-attach patch if failure of 
> small test(s) prevented medium / large tests from running.
> HBASE-18167 was a recent example where TestSimpleRpcScheduler failed.
> We should explicitly mark failed small test(s) so that people know a big 
> portion of unit tests haven't been run.
> This would reduce potential test failure in Jenkins builds if committer 
> doesn't pay attention (that failed test was small test).



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

Re: [INFO] Failing Precommit Builds - HBASE-19042

[Duo Zhang]

Filed HBASE-19055 and pushed the patch to all active branches there.

Now all our pre commit checks are switched to use OpenJDK8.

Thanks all.

2017-10-20 9:01 GMT+08:00 张铎(Duo Zhang) :

> OK seems the newest one. Let me open a new issue to apply them to other
> branches. Thanks.
>
> 2017-10-20 8:36 GMT+08:00 张铎(Duo Zhang) :
>
>> We need patches for all branches starting from branch-1.1. So which
>> version do you commit for HBASE-19042? I can apply the same tricks to other
>> branches.
>>
>> Thanks.
>>
>> 2017-10-20 7:41 GMT+08:00 Mike Drob :
>>
>>> It looks like branch-1 precommit is still broken, we don't have a JIRA
>>> for
>>> it yet though. The fix isn't as straightforward there so it will take a
>>> little more time. Thank you to Ted Yu for bringing this to my attention.
>>>
>>> And huge thank you to Duo, Misty, Sean, and Peter for their parts to
>>> resolve the original issue. It is a great example of the community
>>> working
>>> together.
>>>
>>> Mike
>>>
>>> On Thu, Oct 19, 2017, 4:44 PM Mike Drob  wrote:
>>>
>>> > This issue should be resolved now. I went through and tried to manually
>>> > trigger a precommit on Jenkins for issues where I saw failed precommit
>>> > runs, but can't guarantee that I caught everything.
>>> >
>>> > We are now using openjdk-8 for our precommit runs. Please be vigilant
>>> for
>>> > things that you think might be subtle bugs due to switching JDK
>>> vendors and
>>> > report them. These should be rare, but have cropped up from time to
>>> time.
>>> >
>>> > Thanks,
>>> > Mike
>>> >
>>> > On Wed, Oct 18, 2017 at 8:57 PM, Sean Busbey 
>>> > wrote:
>>> >
>>> >> Thanks for the heads up and thanks to the folks digging in on this.
>>> >>
>>> >> Great find Peter!
>>> >>
>>> >> On Oct 18, 2017 8:52 PM, "Mike Drob"  wrote:
>>> >>
>>> >> > Hi devs,
>>> >> >
>>> >> > Wanted to send a quick note, since some of you have noticed our
>>> >> precommit
>>> >> > failing with mysterious docker errors.
>>> >> >
>>> >> > Our Peter has diagnosed this as Oracle changing their download URL
>>> when
>>> >> > releasing the latest update of Java 8. There's a few different
>>> proposed
>>> >> > solutions here, the final fix will be tracked in
>>> >> > https://issues.apache.org/jira/browse/HBASE-19042
>>> >> >
>>> >> > We understand that this is frustrating for folks trying to submit
>>> >> patches
>>> >> > currently, and appreciate your patience while waiting for a
>>> solution. If
>>> >> > you have questions, comments, concerns, or suggestions, please reply
>>> >> here
>>> >> > or on the JIRA.
>>> >> >
>>> >> > Thanks,
>>> >> > Mike
>>> >> >
>>> >>
>>> >
>>> >
>>>
>>
>>
>

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

[Guanghao Zhang]

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.patch, 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) 
> 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 
> > > branch
> > > to master now.
> > >
> > > Any concerns ?
> > >
> > > Thanks.
> > >
> >
>

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

[Ted Yu]

Some of recent patches, such as HBASE-18368-HBASE-18410.v2.patch, 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) 
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 
> > branch
> > to master now.
> >
> > Any concerns ?
> >
> > Thanks.
> >
>

[jira] [Created] (HBASE-19055) Backport HBASE-19042 to other active branches

[Duo Zhang (JIRA)]

Duo Zhang created HBASE-19055:
-

 Summary: Backport HBASE-19042 to other active branches
 Key: HBASE-19055
 URL: https://issues.apache.org/jira/browse/HBASE-19055
 Project: HBase
  Issue Type: Bug
Reporter: Duo Zhang
Assignee: Duo Zhang
 Fix For: 1.4.0, 1.3.2, 1.5.0, 1.2.7, 1.1.13


Mainly the jdk switching. And also some other dependencies upgrade.



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

Re: [INFO] Failing Precommit Builds - HBASE-19042

[Duo Zhang]

OK seems the newest one. Let me open a new issue to apply them to other
branches. Thanks.

2017-10-20 8:36 GMT+08:00 张铎(Duo Zhang) :

> We need patches for all branches starting from branch-1.1. So which
> version do you commit for HBASE-19042? I can apply the same tricks to other
> branches.
>
> Thanks.
>
> 2017-10-20 7:41 GMT+08:00 Mike Drob :
>
>> It looks like branch-1 precommit is still broken, we don't have a JIRA for
>> it yet though. The fix isn't as straightforward there so it will take a
>> little more time. Thank you to Ted Yu for bringing this to my attention.
>>
>> And huge thank you to Duo, Misty, Sean, and Peter for their parts to
>> resolve the original issue. It is a great example of the community working
>> together.
>>
>> Mike
>>
>> On Thu, Oct 19, 2017, 4:44 PM Mike Drob  wrote:
>>
>> > This issue should be resolved now. I went through and tried to manually
>> > trigger a precommit on Jenkins for issues where I saw failed precommit
>> > runs, but can't guarantee that I caught everything.
>> >
>> > We are now using openjdk-8 for our precommit runs. Please be vigilant
>> for
>> > things that you think might be subtle bugs due to switching JDK vendors
>> and
>> > report them. These should be rare, but have cropped up from time to
>> time.
>> >
>> > Thanks,
>> > Mike
>> >
>> > On Wed, Oct 18, 2017 at 8:57 PM, Sean Busbey 
>> > wrote:
>> >
>> >> Thanks for the heads up and thanks to the folks digging in on this.
>> >>
>> >> Great find Peter!
>> >>
>> >> On Oct 18, 2017 8:52 PM, "Mike Drob"  wrote:
>> >>
>> >> > Hi devs,
>> >> >
>> >> > Wanted to send a quick note, since some of you have noticed our
>> >> precommit
>> >> > failing with mysterious docker errors.
>> >> >
>> >> > Our Peter has diagnosed this as Oracle changing their download URL
>> when
>> >> > releasing the latest update of Java 8. There's a few different
>> proposed
>> >> > solutions here, the final fix will be tracked in
>> >> > https://issues.apache.org/jira/browse/HBASE-19042
>> >> >
>> >> > We understand that this is frustrating for folks trying to submit
>> >> patches
>> >> > currently, and appreciate your patience while waiting for a
>> solution. If
>> >> > you have questions, comments, concerns, or suggestions, please reply
>> >> here
>> >> > or on the JIRA.
>> >> >
>> >> > Thanks,
>> >> > Mike
>> >> >
>> >>
>> >
>> >
>>
>
>

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

[Duo Zhang]

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 
> branch
> to master now.
>
> Any concerns ?
>
> Thanks.
>

Re: [INFO] Failing Precommit Builds - HBASE-19042

[Duo Zhang]

We need patches for all branches starting from branch-1.1. So which version
do you commit for HBASE-19042? I can apply the same tricks to other
branches.

Thanks.

2017-10-20 7:41 GMT+08:00 Mike Drob :

> It looks like branch-1 precommit is still broken, we don't have a JIRA for
> it yet though. The fix isn't as straightforward there so it will take a
> little more time. Thank you to Ted Yu for bringing this to my attention.
>
> And huge thank you to Duo, Misty, Sean, and Peter for their parts to
> resolve the original issue. It is a great example of the community working
> together.
>
> Mike
>
> On Thu, Oct 19, 2017, 4:44 PM Mike Drob  wrote:
>
> > This issue should be resolved now. I went through and tried to manually
> > trigger a precommit on Jenkins for issues where I saw failed precommit
> > runs, but can't guarantee that I caught everything.
> >
> > We are now using openjdk-8 for our precommit runs. Please be vigilant for
> > things that you think might be subtle bugs due to switching JDK vendors
> and
> > report them. These should be rare, but have cropped up from time to time.
> >
> > Thanks,
> > Mike
> >
> > On Wed, Oct 18, 2017 at 8:57 PM, Sean Busbey 
> > wrote:
> >
> >> Thanks for the heads up and thanks to the folks digging in on this.
> >>
> >> Great find Peter!
> >>
> >> On Oct 18, 2017 8:52 PM, "Mike Drob"  wrote:
> >>
> >> > Hi devs,
> >> >
> >> > Wanted to send a quick note, since some of you have noticed our
> >> precommit
> >> > failing with mysterious docker errors.
> >> >
> >> > Our Peter has diagnosed this as Oracle changing their download URL
> when
> >> > releasing the latest update of Java 8. There's a few different
> proposed
> >> > solutions here, the final fix will be tracked in
> >> > https://issues.apache.org/jira/browse/HBASE-19042
> >> >
> >> > We understand that this is frustrating for folks trying to submit
> >> patches
> >> > currently, and appreciate your patience while waiting for a solution.
> If
> >> > you have questions, comments, concerns, or suggestions, please reply
> >> here
> >> > or on the JIRA.
> >> >
> >> > Thanks,
> >> > Mike
> >> >
> >>
> >
> >
>

[DISCUSS] Merge FilterList Improvement - Branch HBASE-18410

[OpenInx]

Hi All :


All subtasks have been resolved except HBASE-18993
, I think it's time to
merge HBASE-18410  branch
to master now.

Any concerns ?

Thanks.

Re: [INFO] Failing Precommit Builds - HBASE-19042

[Mike Drob]

It looks like branch-1 precommit is still broken, we don't have a JIRA for
it yet though. The fix isn't as straightforward there so it will take a
little more time. Thank you to Ted Yu for bringing this to my attention.

And huge thank you to Duo, Misty, Sean, and Peter for their parts to
resolve the original issue. It is a great example of the community working
together.

Mike

On Thu, Oct 19, 2017, 4:44 PM Mike Drob  wrote:

> This issue should be resolved now. I went through and tried to manually
> trigger a precommit on Jenkins for issues where I saw failed precommit
> runs, but can't guarantee that I caught everything.
>
> We are now using openjdk-8 for our precommit runs. Please be vigilant for
> things that you think might be subtle bugs due to switching JDK vendors and
> report them. These should be rare, but have cropped up from time to time.
>
> Thanks,
> Mike
>
> On Wed, Oct 18, 2017 at 8:57 PM, Sean Busbey 
> wrote:
>
>> Thanks for the heads up and thanks to the folks digging in on this.
>>
>> Great find Peter!
>>
>> On Oct 18, 2017 8:52 PM, "Mike Drob"  wrote:
>>
>> > Hi devs,
>> >
>> > Wanted to send a quick note, since some of you have noticed our
>> precommit
>> > failing with mysterious docker errors.
>> >
>> > Our Peter has diagnosed this as Oracle changing their download URL when
>> > releasing the latest update of Java 8. There's a few different proposed
>> > solutions here, the final fix will be tracked in
>> > https://issues.apache.org/jira/browse/HBASE-19042
>> >
>> > We understand that this is frustrating for folks trying to submit
>> patches
>> > currently, and appreciate your patience while waiting for a solution. If
>> > you have questions, comments, concerns, or suggestions, please reply
>> here
>> > or on the JIRA.
>> >
>> > Thanks,
>> > Mike
>> >
>>
>
>

Re: [INFO] Failing Precommit Builds - HBASE-19042

[Mike Drob]

This issue should be resolved now. I went through and tried to manually
trigger a precommit on Jenkins for issues where I saw failed precommit
runs, but can't guarantee that I caught everything.

We are now using openjdk-8 for our precommit runs. Please be vigilant for
things that you think might be subtle bugs due to switching JDK vendors and
report them. These should be rare, but have cropped up from time to time.

Thanks,
Mike

On Wed, Oct 18, 2017 at 8:57 PM, Sean Busbey  wrote:

> Thanks for the heads up and thanks to the folks digging in on this.
>
> Great find Peter!
>
> On Oct 18, 2017 8:52 PM, "Mike Drob"  wrote:
>
> > Hi devs,
> >
> > Wanted to send a quick note, since some of you have noticed our precommit
> > failing with mysterious docker errors.
> >
> > Our Peter has diagnosed this as Oracle changing their download URL when
> > releasing the latest update of Java 8. There's a few different proposed
> > solutions here, the final fix will be tracked in
> > https://issues.apache.org/jira/browse/HBASE-19042
> >
> > We understand that this is frustrating for folks trying to submit patches
> > currently, and appreciate your patience while waiting for a solution. If
> > you have questions, comments, concerns, or suggestions, please reply here
> > or on the JIRA.
> >
> > Thanks,
> > Mike
> >
>

[jira] [Created] (HBASE-19054) Switch precommit docker image to one based on maven images

[Mike Drob (JIRA)]

Mike Drob created HBASE-19054:
-

 Summary: Switch precommit docker image to one based on maven images
 Key: HBASE-19054
 URL: https://issues.apache.org/jira/browse/HBASE-19054
 Project: HBase
  Issue Type: Bug
  Components: build, community
Reporter: Mike Drob


In HBASE-19042 we discuss moving to a maven-based image for docker instead of 
going through gymnastics ourselves. We got a short term fix in there, but let's 
do the bulk of the cleanup here.



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

[jira] [Created] (HBASE-19053) Split out o.a.h.h.http from hbase-server into a separate module

[Appy (JIRA)]

Appy created HBASE-19053:


 Summary: Split out o.a.h.h.http from hbase-server into a separate 
module
 Key: HBASE-19053
 URL: https://issues.apache.org/jira/browse/HBASE-19053
 Project: HBase
  Issue Type: Bug
Reporter: Appy
Assignee: Appy






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

Re: [DISCUSS] Slack Archives

[Mike Drob]

I went ahead and joined on the-asf.slack.com and created an #hbase channel.
There are lots of channels for different projects already.

Anybody with an @apache.org email can join and anybody that is already
joined can invite others.

I don't think there's any concept of 'official' channels, but it does
appear to be the official slack team.

On Sat, Oct 14, 2017 at 9:28 PM, Mikhail Antonov 
wrote:

> If ASF has "official" slack channels then migrating over to it might be
> just the logical thing to do?
>
> -Mikhail
>
> On Sat, Oct 14, 2017 at 7:46 AM, Mike Drob  wrote:
>
> > Prefacing this with the disclaimer that I'm not a regular slack user, so
> I
> > don't know what serves those users best.
> >
> > Are we currently in the free slack tier with limited history? Would we
> > consider something like using slackarchive.io at community tier to get
> > searchable archives? This also provides for a larger knowledge base for
> non
> > users.
> >
> > Alternatively, should we entertain migrating to the general ASF slack
> team
> > and carve out a few channels there?
> >
> > Mike
> >
>
>
>
> --
> Thanks,
> Michael Antonov
>

[jira] [Created] (HBASE-19052) Backport CellComparatorImpl related changes to branch-1.x

[Ted Yu (JIRA)]

Ted Yu created HBASE-19052:
--

 Summary: Backport CellComparatorImpl related changes to branch-1.x
 Key: HBASE-19052
 URL: https://issues.apache.org/jira/browse/HBASE-19052
 Project: HBase
  Issue Type: Bug
Reporter: Ted Yu


HBASE-18945 has gone into branch-2 .
Let's consider rolling upgrade scenario from 1.x to 2.0 where there're three 
servers: s1, s2, s3

s1 is upgraded to 2.0 first. It flushes to hfile in region r1 with 
CellComparatorImpl written in the hfile trailer.
Somehow s1 crashes and master assigns r1 to s2 which is still running 1.x
The following code in FixedFileTrailer would be triggered:
{code}
  try {
comparatorKlass = (Class) 
Class.forName(comparatorClassName);
  } catch (ClassNotFoundException e) {
throw new IOException(e);
  }
{code}
since s2 is not aware of CellComparatorImpl.

This issue is to backport CellComparatorImpl related change to branch-1.x



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

[jira] [Created] (HBASE-19051) Add new split algorithm for num string

[Yun Zhao (JIRA)]

Yun Zhao created HBASE-19051:


 Summary: Add new split algorithm for num string
 Key: HBASE-19051
 URL: https://issues.apache.org/jira/browse/HBASE-19051
 Project: HBase
  Issue Type: Improvement
Reporter: Yun Zhao
Priority: Minor


We will use the reversed sequential number or phone number as the first part of 
rowkey, there is no split algorithm to create a pre-split table, only by 
specify the split points.
{code}
create 't1','f', SPLITS => ['1','2','3','4','5','6','7','8','9']
{code}

Add new split algorithm DecStringSplit.
{code}
create 't2','f', { NUMREGIONS => 10 , SPLITALGO => 'DecStringSplit' }
{code}




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

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

[Josh Elser]

Thanks all!

On 10/18/17 12:46 AM, 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 instead the result of its own (Flow) Scan


result.


Not sure how we'd do alternative here; Timeline Server is keeping Tags
internally.


On Wed, Oct 11, 2017 at 10:59 AM, Andrew Purtell 

[jira] [Created] (HBASE-19050) Improve javadoc of Scan#setMvccReadPoint

[ramkrishna.s.vasudevan (JIRA)]

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

 Summary: Improve javadoc of Scan#setMvccReadPoint
 Key: HBASE-19050
 URL: https://issues.apache.org/jira/browse/HBASE-19050
 Project: HBase
  Issue Type: Task
  Components: scan
Reporter: ramkrishna.s.vasudevan
Assignee: ramkrishna.s.vasudevan
Priority: Minor
 Fix For: 2.0.0-beta-1


This is to improve the javadoc of scan#setMvccReadPoint. Ya it was added for 
internal thing so that the scan is able to use the mvcc point. 
But the java doc is not explicit and does not tell the importance of using it 
and I think internally the code just ignores it. I can confirm that once where 
exactly it happens but javadoc should  highlight it I believe. 
At least we should mention that user setting any value will be ignored.



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

[jira] [Created] (HBASE-19049) Update kerby to 1.0.0 GA release

[Sean Busbey (JIRA)]

Sean Busbey created HBASE-19049:
---

 Summary: Update kerby to 1.0.0 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: 2.0.0-alpha-4


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] [Resolved] (HBASE-18977) Reenable test of filterlist using MUST_PASS_ONE and two familyfilters

[Zheng Hu (JIRA)]

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

Zheng Hu resolved HBASE-18977.
--
Resolution: Fixed

> Reenable test of filterlist using MUST_PASS_ONE and two familyfilters
> -
>
> Key: HBASE-18977
> URL: https://issues.apache.org/jira/browse/HBASE-18977
> Project: HBase
>  Issue Type: Sub-task
>  Components: Filters
>Affects Versions: HBASE-18410
>Reporter: Sean Busbey
>Assignee: Zheng Hu
>Priority: Blocker
> Fix For: HBASE-18410
>
>
> The HBASE-18410 feature branch started with the test from HBASE-18957 
> disabled. we need to enable it before merging.



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

[jira] [Created] (HBASE-19048) Cleanup MasterObserver hooks which takes IA private params

[Anoop Sam John (JIRA)]

Anoop Sam John created HBASE-19048:
--

 Summary: Cleanup MasterObserver hooks which takes IA private params
 Key: HBASE-19048
 URL: https://issues.apache.org/jira/browse/HBASE-19048
 Project: HBase
  Issue Type: Sub-task
Reporter: Anoop Sam John
 Fix For: 2.0.0-alpha-4


These are the ones in MasterObserver
preAbortProcedure   ProcedureExecutor
postGetProcedures   Procedure
postGetLocksLockedResource
preRequestLock  LockType
postRequestLock LockType
preLockHeartbeatLockProcedure
postLockHeartbeat   LockProcedure



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

[jira] [Created] (HBASE-19047) CP exposed Scanner types should not extend Shipper

[Anoop Sam John (JIRA)]

Anoop Sam John created HBASE-19047:
--

 Summary: CP exposed Scanner types should not extend Shipper
 Key: HBASE-19047
 URL: https://issues.apache.org/jira/browse/HBASE-19047
 Project: HBase
  Issue Type: Sub-task
Reporter: Anoop Sam John
Assignee: Anoop Sam John
 Fix For: 2.0.0-alpha-4


Shipper is a IA.Private interface and very much internal.. 
Right now CP exposed RegionScanner is extending this and so exposing the 
shipped() method. This by mistake is called, can harm the correctness of the 
cells in the Results.

preScannerOpen() allowing to return a new Scanner is also problematic now.  
This can allow users to create a Region scanner from Region and then wrap it 
and return back (Well same can be done by postScannerOpen also), it can so 
happen that the wrapper is not implementing the shipped() properly.  In any way 
exposing the shipped () is problematic.

Solution
1. Remove preScannerOpen() , the use case I can think of is wrapping the 
original scanner. The original scanner can be created by Region.getScanner way 
only..  May be no need to remove this hook.  Just remove the ability for it to 
return a RegionScanner instance.  Call this with the Scan object and the CP can 
change the Scan object if they want.
2. Let RegionScanner not extending Shipper but only RegionScannerImpl 
implements this
3. We have ref to the RegionScanner created by core and let that be used by 
RegionScannerShippedCallBack when the post hook doing a wrap.



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

[jira] [Created] (HBASE-19046) RegionObserver#postCompactSelection Passing an ImmutableList param of PB type

[Anoop Sam John (JIRA)]

Anoop Sam John created HBASE-19046:
--

 Summary: RegionObserver#postCompactSelection  Passing an 
ImmutableList param of PB type
 Key: HBASE-19046
 URL: https://issues.apache.org/jira/browse/HBASE-19046
 Project: HBase
  Issue Type: Sub-task
Reporter: Anoop Sam John
Assignee: Anoop Sam John
 Fix For: 2.0.0-alpha-4


Dont think there is any specific need for passing this PB type.  We can just 
pass an unmodifiableList list object. Javadoc can say this is an 
unmodifiableList .  Thats it . No need  that the type itself to be Immutable...



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

[jira] [Created] (HBASE-19045) Deprecate RegionObserver#postInstantiateDeleteTracker

[Anoop Sam John (JIRA)]

Anoop Sam John created HBASE-19045:
--

 Summary: Deprecate RegionObserver#postInstantiateDeleteTracker
 Key: HBASE-19045
 URL: https://issues.apache.org/jira/browse/HBASE-19045
 Project: HBase
  Issue Type: Sub-task
Reporter: Anoop Sam John
Assignee: Anoop Sam John
 Fix For: 2.0.0-alpha-4


Too much of an internal thing to be exposed to CPs.
This was added a VC feature as that is implemented as a CP , no other choice 
then.
We can deprecate this now with a warn that not be used.
We might be changing AC/VC etc to be core service than CP impl for 3.0 (?)



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

[jira] [Created] (HBASE-19044) "Regions in Transition" blocked the balance process

[nilone (JIRA)]

nilone created HBASE-19044:
--

 Summary: "Regions in Transition" blocked the balance process
 Key: HBASE-19044
 URL: https://issues.apache.org/jira/browse/HBASE-19044
 Project: HBase
  Issue Type: Bug
Affects Versions: 1.0.0
Reporter: nilone


1、regions assigned unbalanced seriously
2、many "Regions in Transition" shows in the hmaster UI ,keep state for long time
3、Some application reported part of table querys timeout

when manual execute command "balance_switch true", there is no balance effetct

I know empty zookeeper /hbase/region-in-transition node can get some result,
but we don't want to restart the hmaster service, becase the region loading can 
take a long time.

so how to solve the problem ?



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