[jira] [Created] (HBASE-16988) Document for improve transparent table/CF encryption with Commons Crypto

2016-11-01 Thread Dapeng Sun (JIRA) 
Dapeng Sun created HBASE-16988:
--

 Summary: Document for improve transparent table/CF encryption with 
Commons Crypto
 Key: HBASE-16988
 URL: https://issues.apache.org/jira/browse/HBASE-16988
 Project: HBase
  Issue Type: Improvement
  Components: documentation
Affects Versions: 2.0.0
Reporter: Dapeng Sun
Assignee: Dapeng Sun


update the document for improve transparent table/CF encryption with Commons 
Crypto



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

Re: Hangout on Slack?

2016-11-01 Thread Stack 
Yes.

Who is admin. Do we know who adds 'users' when they ask on dev?

S

On Tue, Nov 1, 2016 at 6:08 PM, Dima Spivak  wrote:

> I opened HBASE-16413 a while back as a beginner JIRA, but maybe we should
> just do it?
>
> -Dima
>
> On Tue, Nov 1, 2016 at 6:06 PM, Stack  wrote:
>
> > Related to a request to join our Slack channel on another thread, do you
> > have to have an apache.org id to join up?
> >
> > The Slack channel should be published on the website? Is it there (I
> don't
> > see it on a quick search on site and in refguide but I could be blind).
> >
> > Thanks,
> > S
> >
> >
> > On Mon, Jun 20, 2016 at 2:13 PM, Apekshit Sharma 
> > wrote:
> >
> > > Anyone can join anytime with @apache.org email id using following
> link.
> > > https://apache-hbase.slack.com/x-37639653748-52658243986/signup
> > >
> > > Sorry, but slack doesn't allow doing same for @gmail.com email ids.
> > >
> > > On Mon, Jun 20, 2016 at 11:36 AM, Apekshit Sharma 
> > > wrote:
> > >
> > > > Here's new link:
> > > > https://apache-hbase.slack.com/shared_invite/
> > > NTI1OTc5NzQ4ODctMTQ2NjQ0Nzc0NC01ZDg1YjIyZjcw
> > > > Sorry can't do anything about expiration, that's slack's policy: no
> > link
> > > > active more than 48 hours.
> > > >
> > > > On Mon, Jun 20, 2016 at 9:14 AM, Sean Busbey 
> > > wrote:
> > > >
> > > >> Appy, could you make another link? if there's a "no-expiration"
> option
> > > >> that would be best.
> > > >>
> > > >> On Fri, Jun 17, 2016 at 7:23 PM, Apekshit Sharma  >
> > > >> wrote:
> > > >> > Or you can join the team using this link:
> > > >> >
> > > >> https://apache-hbase.slack.com/shared_invite/
> > > NTIxMTE4NTQwMzYtMTQ2NjIwOTMwMi1kMzc2YzkwYTJm
> > > >> > It expires on Sunday.
> > > >> >
> > > >> > On Fri, Jun 17, 2016 at 4:43 PM, Apekshit Sharma <
> a...@cloudera.com
> > >
> > > >> wrote:
> > > >> >
> > > >> >> Created slack team apache-hbase.slack.com.
> > > >> >> It has two channels: users and dev.
> > > >> >> I still have to figure out how to allow guests to join 'users'
> > group.
> > > >> >> I have sent invites to some people to seed the group, i think you
> > > >> should
> > > >> >> be able to add others. If not, please let me know.
> > > >> >>
> > > >> >> On Thu, Jun 16, 2016 at 3:20 PM, Dima Spivak <
> dspi...@cloudera.com
> > >
> > > >> wrote:
> > > >> >>
> > > >> >>> +1. Even with all the bots, I feel really lonely in the #hbase
> > IRC.
> > > :)
> > > >> >>>
> > > >> >>> -Dima
> > > >> >>>
> > > >> >>> On Thu, Jun 16, 2016 at 3:15 PM, Apekshit Sharma <
> > a...@cloudera.com
> > > >
> > > >> >>> wrote:
> > > >> >>>
> > > >> >>> > Brining it up again, because I really feel that we should do
> > this.
> > > >> It'll
> > > >> >>> > make communicating with community so much easier, both
> > broadcasts
> > > >> and
> > > >> >>> 1-1
> > > >> >>> > pings (with people not in same org). Inside the slack group,
> > we'll
> > > >> also
> > > >> >>> be
> > > >> >>> > able to create separate channels for users and dev. For those
> > who
> > > >> >>> haven't
> > > >> >>> > tried Slack yet, I am fairly certain that you'll like it.
> > > >> >>> > Unless someone says otherwise, I'll go ahead and do this
> > tonight.
> > > >> >>> > We'll post a redirect message on existing IRC. I'll update the
> > > hbase
> > > >> >>> book
> > > >> >>> > too.
> > > >> >>> > Thanks
> > > >> >>> >
> > > >> >>> > -- Appy
> > > >> >>> >
> > > >> >>> >
> > > >> >>> >
> > > >> >>> > On Sun, May 15, 2016 at 9:19 PM, Stack 
> > wrote:
> > > >> >>> >
> > > >> >>> > > On Mon, Apr 25, 2016 at 4:05 PM, Apekshit Sharma <
> > > >> a...@cloudera.com>
> > > >> >>> > > wrote:
> > > >> >>> > >
> > > >> >>> > > > ...
> > > >> >>> > > > Anyways, let's revive the old tradition because it will
> > > >> certainly be
> > > >> >>> > > useful
> > > >> >>> > > > to hang out in a room for real-time discussions.
> > > >> >>> > > >
> > > >> >>> > >
> > > >> >>> > >
> > > >> >>> > > Just to day that there are signs of life over in IRC over
> last
> > > few
> > > >> >>> days.
> > > >> >>> > > Suggest we nurture and then suggest move to Slack if wanted
> > > >> (Heard an
> > > >> >>> > > argument on friday that Slack has lower barrier to entry...
> Do
> > > >> others
> > > >> >>> > > believe this?)
> > > >> >>> > >
> > > >> >>> > > Thanks,
> > > >> >>> > > St.Ack
> > > >> >>> > >
> > > >> >>> > >
> > > >> >>> > >
> > > >> >>> > > > -- Appy
> > > >> >>> > > >
> > > >> >>> > >
> > > >> >>> >
> > > >> >>> >
> > > >> >>> >
> > > >> >>> > --
> > > >> >>> >
> > > >> >>> > Regards
> > > >> >>> >
> > > >> >>> > Apekshit Sharma | Software Engineer, Cloudera | Palo Alto,
> > > >> California |
> > > >> >>> > 650-963-6311
> > > >> >>> >
> > > >> >>>
> > > >> >>
> > > >> >>
> > > >> >>
> > > >> >> --
> > > >> >>
> > > >> >> -- Appy
> > > >> >>
> > > >> >
> > > >> >
> > > >> >
> > > >> > --
> > > >> >
> > > >> > -- Appy
> > > >>
> > > >>

Re: Hangout on Slack?

2016-11-01 Thread Dima Spivak 
I opened HBASE-16413 a while back as a beginner JIRA, but maybe we should
just do it?

-Dima

On Tue, Nov 1, 2016 at 6:06 PM, Stack  wrote:

> Related to a request to join our Slack channel on another thread, do you
> have to have an apache.org id to join up?
>
> The Slack channel should be published on the website? Is it there (I don't
> see it on a quick search on site and in refguide but I could be blind).
>
> Thanks,
> S
>
>
> On Mon, Jun 20, 2016 at 2:13 PM, Apekshit Sharma 
> wrote:
>
> > Anyone can join anytime with @apache.org email id using following link.
> > https://apache-hbase.slack.com/x-37639653748-52658243986/signup
> >
> > Sorry, but slack doesn't allow doing same for @gmail.com email ids.
> >
> > On Mon, Jun 20, 2016 at 11:36 AM, Apekshit Sharma 
> > wrote:
> >
> > > Here's new link:
> > > https://apache-hbase.slack.com/shared_invite/
> > NTI1OTc5NzQ4ODctMTQ2NjQ0Nzc0NC01ZDg1YjIyZjcw
> > > Sorry can't do anything about expiration, that's slack's policy: no
> link
> > > active more than 48 hours.
> > >
> > > On Mon, Jun 20, 2016 at 9:14 AM, Sean Busbey 
> > wrote:
> > >
> > >> Appy, could you make another link? if there's a "no-expiration" option
> > >> that would be best.
> > >>
> > >> On Fri, Jun 17, 2016 at 7:23 PM, Apekshit Sharma 
> > >> wrote:
> > >> > Or you can join the team using this link:
> > >> >
> > >> https://apache-hbase.slack.com/shared_invite/
> > NTIxMTE4NTQwMzYtMTQ2NjIwOTMwMi1kMzc2YzkwYTJm
> > >> > It expires on Sunday.
> > >> >
> > >> > On Fri, Jun 17, 2016 at 4:43 PM, Apekshit Sharma  >
> > >> wrote:
> > >> >
> > >> >> Created slack team apache-hbase.slack.com.
> > >> >> It has two channels: users and dev.
> > >> >> I still have to figure out how to allow guests to join 'users'
> group.
> > >> >> I have sent invites to some people to seed the group, i think you
> > >> should
> > >> >> be able to add others. If not, please let me know.
> > >> >>
> > >> >> On Thu, Jun 16, 2016 at 3:20 PM, Dima Spivak  >
> > >> wrote:
> > >> >>
> > >> >>> +1. Even with all the bots, I feel really lonely in the #hbase
> IRC.
> > :)
> > >> >>>
> > >> >>> -Dima
> > >> >>>
> > >> >>> On Thu, Jun 16, 2016 at 3:15 PM, Apekshit Sharma <
> a...@cloudera.com
> > >
> > >> >>> wrote:
> > >> >>>
> > >> >>> > Brining it up again, because I really feel that we should do
> this.
> > >> It'll
> > >> >>> > make communicating with community so much easier, both
> broadcasts
> > >> and
> > >> >>> 1-1
> > >> >>> > pings (with people not in same org). Inside the slack group,
> we'll
> > >> also
> > >> >>> be
> > >> >>> > able to create separate channels for users and dev. For those
> who
> > >> >>> haven't
> > >> >>> > tried Slack yet, I am fairly certain that you'll like it.
> > >> >>> > Unless someone says otherwise, I'll go ahead and do this
> tonight.
> > >> >>> > We'll post a redirect message on existing IRC. I'll update the
> > hbase
> > >> >>> book
> > >> >>> > too.
> > >> >>> > Thanks
> > >> >>> >
> > >> >>> > -- Appy
> > >> >>> >
> > >> >>> >
> > >> >>> >
> > >> >>> > On Sun, May 15, 2016 at 9:19 PM, Stack 
> wrote:
> > >> >>> >
> > >> >>> > > On Mon, Apr 25, 2016 at 4:05 PM, Apekshit Sharma <
> > >> a...@cloudera.com>
> > >> >>> > > wrote:
> > >> >>> > >
> > >> >>> > > > ...
> > >> >>> > > > Anyways, let's revive the old tradition because it will
> > >> certainly be
> > >> >>> > > useful
> > >> >>> > > > to hang out in a room for real-time discussions.
> > >> >>> > > >
> > >> >>> > >
> > >> >>> > >
> > >> >>> > > Just to day that there are signs of life over in IRC over last
> > few
> > >> >>> days.
> > >> >>> > > Suggest we nurture and then suggest move to Slack if wanted
> > >> (Heard an
> > >> >>> > > argument on friday that Slack has lower barrier to entry... Do
> > >> others
> > >> >>> > > believe this?)
> > >> >>> > >
> > >> >>> > > Thanks,
> > >> >>> > > St.Ack
> > >> >>> > >
> > >> >>> > >
> > >> >>> > >
> > >> >>> > > > -- Appy
> > >> >>> > > >
> > >> >>> > >
> > >> >>> >
> > >> >>> >
> > >> >>> >
> > >> >>> > --
> > >> >>> >
> > >> >>> > Regards
> > >> >>> >
> > >> >>> > Apekshit Sharma | Software Engineer, Cloudera | Palo Alto,
> > >> California |
> > >> >>> > 650-963-6311
> > >> >>> >
> > >> >>>
> > >> >>
> > >> >>
> > >> >>
> > >> >> --
> > >> >>
> > >> >> -- Appy
> > >> >>
> > >> >
> > >> >
> > >> >
> > >> > --
> > >> >
> > >> > -- Appy
> > >>
> > >>
> > >>
> > >> --
> > >> busbey
> > >>
> > >
> > >
> > >
> > > --
> > >
> > > -- Appy
> > >
> >
> >
> >
> > --
> >
> > -- Appy
> >
>

Re: Hangout on Slack?

2016-11-01 Thread Stack 
Related to a request to join our Slack channel on another thread, do you
have to have an apache.org id to join up?

The Slack channel should be published on the website? Is it there (I don't
see it on a quick search on site and in refguide but I could be blind).

Thanks,
S


On Mon, Jun 20, 2016 at 2:13 PM, Apekshit Sharma  wrote:

> Anyone can join anytime with @apache.org email id using following link.
> https://apache-hbase.slack.com/x-37639653748-52658243986/signup
>
> Sorry, but slack doesn't allow doing same for @gmail.com email ids.
>
> On Mon, Jun 20, 2016 at 11:36 AM, Apekshit Sharma 
> wrote:
>
> > Here's new link:
> > https://apache-hbase.slack.com/shared_invite/
> NTI1OTc5NzQ4ODctMTQ2NjQ0Nzc0NC01ZDg1YjIyZjcw
> > Sorry can't do anything about expiration, that's slack's policy: no link
> > active more than 48 hours.
> >
> > On Mon, Jun 20, 2016 at 9:14 AM, Sean Busbey 
> wrote:
> >
> >> Appy, could you make another link? if there's a "no-expiration" option
> >> that would be best.
> >>
> >> On Fri, Jun 17, 2016 at 7:23 PM, Apekshit Sharma 
> >> wrote:
> >> > Or you can join the team using this link:
> >> >
> >> https://apache-hbase.slack.com/shared_invite/
> NTIxMTE4NTQwMzYtMTQ2NjIwOTMwMi1kMzc2YzkwYTJm
> >> > It expires on Sunday.
> >> >
> >> > On Fri, Jun 17, 2016 at 4:43 PM, Apekshit Sharma 
> >> wrote:
> >> >
> >> >> Created slack team apache-hbase.slack.com.
> >> >> It has two channels: users and dev.
> >> >> I still have to figure out how to allow guests to join 'users' group.
> >> >> I have sent invites to some people to seed the group, i think you
> >> should
> >> >> be able to add others. If not, please let me know.
> >> >>
> >> >> On Thu, Jun 16, 2016 at 3:20 PM, Dima Spivak 
> >> wrote:
> >> >>
> >> >>> +1. Even with all the bots, I feel really lonely in the #hbase IRC.
> :)
> >> >>>
> >> >>> -Dima
> >> >>>
> >> >>> On Thu, Jun 16, 2016 at 3:15 PM, Apekshit Sharma  >
> >> >>> wrote:
> >> >>>
> >> >>> > Brining it up again, because I really feel that we should do this.
> >> It'll
> >> >>> > make communicating with community so much easier, both broadcasts
> >> and
> >> >>> 1-1
> >> >>> > pings (with people not in same org). Inside the slack group, we'll
> >> also
> >> >>> be
> >> >>> > able to create separate channels for users and dev. For those who
> >> >>> haven't
> >> >>> > tried Slack yet, I am fairly certain that you'll like it.
> >> >>> > Unless someone says otherwise, I'll go ahead and do this tonight.
> >> >>> > We'll post a redirect message on existing IRC. I'll update the
> hbase
> >> >>> book
> >> >>> > too.
> >> >>> > Thanks
> >> >>> >
> >> >>> > -- Appy
> >> >>> >
> >> >>> >
> >> >>> >
> >> >>> > On Sun, May 15, 2016 at 9:19 PM, Stack  wrote:
> >> >>> >
> >> >>> > > On Mon, Apr 25, 2016 at 4:05 PM, Apekshit Sharma <
> >> a...@cloudera.com>
> >> >>> > > wrote:
> >> >>> > >
> >> >>> > > > ...
> >> >>> > > > Anyways, let's revive the old tradition because it will
> >> certainly be
> >> >>> > > useful
> >> >>> > > > to hang out in a room for real-time discussions.
> >> >>> > > >
> >> >>> > >
> >> >>> > >
> >> >>> > > Just to day that there are signs of life over in IRC over last
> few
> >> >>> days.
> >> >>> > > Suggest we nurture and then suggest move to Slack if wanted
> >> (Heard an
> >> >>> > > argument on friday that Slack has lower barrier to entry... Do
> >> others
> >> >>> > > believe this?)
> >> >>> > >
> >> >>> > > Thanks,
> >> >>> > > St.Ack
> >> >>> > >
> >> >>> > >
> >> >>> > >
> >> >>> > > > -- Appy
> >> >>> > > >
> >> >>> > >
> >> >>> >
> >> >>> >
> >> >>> >
> >> >>> > --
> >> >>> >
> >> >>> > Regards
> >> >>> >
> >> >>> > Apekshit Sharma | Software Engineer, Cloudera | Palo Alto,
> >> California |
> >> >>> > 650-963-6311
> >> >>> >
> >> >>>
> >> >>
> >> >>
> >> >>
> >> >> --
> >> >>
> >> >> -- Appy
> >> >>
> >> >
> >> >
> >> >
> >> > --
> >> >
> >> > -- Appy
> >>
> >>
> >>
> >> --
> >> busbey
> >>
> >
> >
> >
> > --
> >
> > -- Appy
> >
>
>
>
> --
>
> -- Appy
>

[jira] [Resolved] (HBASE-16765) New SteppingRegionSplitPolicy, avoid too aggressive spread of regions for small tables.

2016-11-01 Thread Lars Hofhansl (JIRA) 

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

Lars Hofhansl resolved HBASE-16765.
---
   Resolution: Fixed
 Assignee: Lars Hofhansl
Fix Version/s: 1.1.8
   0.98.24
   1.2.4
   1.4.0
   1.3.0
   2.0.0

> New SteppingRegionSplitPolicy, avoid too aggressive spread of regions for 
> small tables.
> ---
>
> Key: HBASE-16765
> URL: https://issues.apache.org/jira/browse/HBASE-16765
> Project: HBase
>  Issue Type: Bug
>Reporter: Lars Hofhansl
>Assignee: Lars Hofhansl
> Fix For: 2.0.0, 1.3.0, 1.4.0, 1.2.4, 0.98.24, 1.1.8
>
> Attachments: 16765-0.98.txt
>
>
> We just did some experiments on some larger clusters and found that while 
> using IncreasingToUpperBoundRegionSplitPolicy generally works well and is 
> very convenient, it does tend to produce too many regions.
> Since the logic is - by design - local, checking the number of regions of the 
> table in question on the local server only, we end with more regions then 
> necessary.



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

Request to Access hbase Slack Channel

2016-11-01 Thread Mahsa Ghafourian 
Hello,

I would like to access hbase slack channel. Would appreciate it if you give 
access to me.


Thanks,
Mahsa

Re: State of 1.3 first RC

2016-11-01 Thread Mikhail Antonov 
Looking - thanks!

-M

On Tue, Nov 1, 2016 at 10:03 AM, Yu Li  wrote:

> Another critical one for your attention sir (patch ready for commit):
> https://issues.apache.org/jira/browse/HBASE-16960
>
> Best Regards,
> Yu
>
> On 31 October 2016 at 16:59, Mikhail Antonov  wrote:
>
> > Hi Yu,
> >
> > sorry I missed that and thanks for reaching out. Let me have a look now
> and
> > comment on the jira.
> >
> > -Mikhail
> >
> > On Mon, Oct 31, 2016 at 12:30 AM, Yu Li  wrote:
> >
> > > I think HBASE-16931 is also a critical issue (oops also in compaction
> > > area...) and should go in 1.3.0, pinged several times there but failed
> to
> > > draw your attention boss (smile). Mind take a look? Thanks.
> > >
> > > Btw, is there any ETA for 1.3.0 yet?
> > >
> > > Best Regards,
> > > Yu
> > >
> > > On 29 October 2016 at 08:17, Mikhail Antonov 
> > wrote:
> > >
> > > > Guys,
> > > >
> > > > I've been working on getting the first RC out this week and want to
> > share
> > > > an update on the current state of the things.
> > > >
> > > >  - HBASE-16951 - was found and fixed, when we don't include
> > > > hbase-archetypes in the tarball assembly
> > > >  - HBASE-16570 - optimization that caused a regression in the
> balancer,
> > > it
> > > > was reverted from 1.3. Once fixed that would go to 1.4 and perhaps
> > 1.3.1.
> > > >  - HBASE-16743 - flaky TestSimpleRpcScheduler, fixed now (I ran
> several
> > > > cycles of 50 iterations each and all have passed).
> > > >
> > > > Now, there's presently one remaining blocker - HBASE-16964, when we
> > don't
> > > > properly handle archiving of store files after compactions (thanks
> Gary
> > > for
> > > > digging into that!).
> > > > See the jira for details.
> > > >
> > > > Also, as a note - the above is a third major bug around compactions
> > that
> > > we
> > > > saw on 1.3 during our testing last month (see also HBASE-16788
> > > > and HBASE-16754)..
> > > > So during the upcoming RC testing let's try to stress this area.
> > > >
> > > > Until 1.3 is out let's consider branch-1.3 to be in a lockdown for
> new
> > > > changes. Ping me if you think there is something that I'm missing
> that
> > > > should go out in 1.3. Otherwise,
> > > > important but non-blocker fixes in flight would go in 1.3.1.
> > > >
> > > > Stay tuned!
> > > > Mikhail
> > > >
> > >
> >
> >
> >
> > --
> > Thanks,
> > Michael Antonov
> >
>



-- 
Thanks,
Michael Antonov

Re: [VOTE] Second release candidate for HBase 1.2.4 is available

2016-11-01 Thread Andrew Purtell 
Please see HBASE-16980. Appears to be a test only issue, so changing my
vote to +1


On Mon, Oct 31, 2016 at 6:41 PM, Andrew Purtell  wrote:

> I did a quick bisect (see HBASE-16980) and the suspect commit went out in
> the previous release, so let me change my vote to -0: This is not a
> regression in this release on the one hand but on the other the unit test
> suite does not pass.
>
> On Mon, Oct 31, 2016 at 6:15 PM, Andrew Purtell 
> wrote:
>
>> -1​
>>
>>
>> Checked signatures: ok
>> Checked sums: ok (md5, sha1)
>> Checked NOTICE and LICENSE files: ok. Still seeing unexpanded velocity
>> macros in binary NOTICE (e.g. "For source see '${dep.url}'.") but not a
>> showstopper
>> Built from source with RAT check: ok (7u80)
>> LTT 1M rows: ok (8u102)
>> ​Unit tests: ​TestRowProcessorEndpoint fails consistently (7u80) -
>> HBASE-16980
>>
>> ​  TestRowProcessorEndpoint.testMultipleRows:246 expected:<3> but was:<2>
>>   TestRowProcessorEndpoint.testReadModifyWrite:184 expected:<101> but
>> was:<91>
>>
>>
>> On Tue, Oct 25, 2016 at 8:17 PM, Sean Busbey  wrote:
>>
>>> The second release candidate for HBase 1.2.4 is available for download
>>> at:
>>>
>>> https://dist.apache.org/repos/dist/dev/hbase/hbase-1.2.4RC1/
>>>
>>> Maven artifacts are also available in a staging repository at:
>>>
>>> https://repository.apache.org/content/repositories/orgapachehbase-1156/
>>>
>>> Artifacts are signed with my key (0D80DB7C) published in our KEYS
>>> file at http://www.apache.org/dist/hbase/KEYS
>>>
>>> The RC corresponds to the signed tag 1.2.4RC1, which currently points
>>> to commit ref
>>>
>>> 67592f3d062743907f8c5ae00dbbe1ae4f69e5af
>>>
>>> The detailed source and binary compatibility report vs 1.2.3 has been
>>> published for your review, at:
>>>
>>> https://dist.apache.org/repos/dist/dev/hbase/hbase-1.2.4RC1/
>>> 1.2.3_1.2.4RC1_compat_report.html
>>>
>>> HBase 1.2.4 is the fourth patch release in the HBase 1.2 line,
>>> continuing on
>>> the theme of bringing a stable, reliable database to the Hadoop and NoSQL
>>> communities. This release includes about 30 bug fixes since 1.2.3.
>>> Critical fixes include:
>>>
>>> * HBASE-16340 Xerces implementation jars removed (incompatible change)
>>> * HBASE-15984 Given failure to parse a given WAL that was closed
>>> cleanly, replay the WAL.
>>> * HBASE-16931 Setting cell's seqId to zero in compaction flow might
>>> cause RS down.
>>> * HBASE-16721 Concurrency issue in WAL unflushed seqId tracking
>>>
>>> The full list of fixes included in this release is available at:
>>>
>>> https://issues.apache.org/jira/secure/ReleaseNote.jspa?proje
>>> ctId=12310753=12338116
>>>
>>> and in the CHANGES.txt file included in the distribution.
>>>
>>> Please try out this candidate and vote +1/-1 on whether we should
>>> release these artifacts as HBase 1.2.4.
>>>
>>> The VOTE will remain open for atleast 72 hours. Given sufficient votes
>>> I would like to close it on November 1st, 2016.
>>>
>>> thanks!
>>>
>>
>>
>>
>> --
>> 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)
>



-- 
Best regards,

   - Andy

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

Re: State of 1.3 first RC

2016-11-01 Thread Yu Li 
Another critical one for your attention sir (patch ready for commit):
https://issues.apache.org/jira/browse/HBASE-16960

Best Regards,
Yu

On 31 October 2016 at 16:59, Mikhail Antonov  wrote:

> Hi Yu,
>
> sorry I missed that and thanks for reaching out. Let me have a look now and
> comment on the jira.
>
> -Mikhail
>
> On Mon, Oct 31, 2016 at 12:30 AM, Yu Li  wrote:
>
> > I think HBASE-16931 is also a critical issue (oops also in compaction
> > area...) and should go in 1.3.0, pinged several times there but failed to
> > draw your attention boss (smile). Mind take a look? Thanks.
> >
> > Btw, is there any ETA for 1.3.0 yet?
> >
> > Best Regards,
> > Yu
> >
> > On 29 October 2016 at 08:17, Mikhail Antonov 
> wrote:
> >
> > > Guys,
> > >
> > > I've been working on getting the first RC out this week and want to
> share
> > > an update on the current state of the things.
> > >
> > >  - HBASE-16951 - was found and fixed, when we don't include
> > > hbase-archetypes in the tarball assembly
> > >  - HBASE-16570 - optimization that caused a regression in the balancer,
> > it
> > > was reverted from 1.3. Once fixed that would go to 1.4 and perhaps
> 1.3.1.
> > >  - HBASE-16743 - flaky TestSimpleRpcScheduler, fixed now (I ran several
> > > cycles of 50 iterations each and all have passed).
> > >
> > > Now, there's presently one remaining blocker - HBASE-16964, when we
> don't
> > > properly handle archiving of store files after compactions (thanks Gary
> > for
> > > digging into that!).
> > > See the jira for details.
> > >
> > > Also, as a note - the above is a third major bug around compactions
> that
> > we
> > > saw on 1.3 during our testing last month (see also HBASE-16788
> > > and HBASE-16754)..
> > > So during the upcoming RC testing let's try to stress this area.
> > >
> > > Until 1.3 is out let's consider branch-1.3 to be in a lockdown for new
> > > changes. Ping me if you think there is something that I'm missing that
> > > should go out in 1.3. Otherwise,
> > > important but non-blocker fixes in flight would go in 1.3.1.
> > >
> > > Stay tuned!
> > > Mikhail
> > >
> >
>
>
>
> --
> Thanks,
> Michael Antonov
>

[jira] [Resolved] (HBASE-16986) Add note on how scanner caching has changed since 0.98 to refguid

2016-11-01 Thread stack (JIRA) 

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

stack resolved HBASE-16986.
---
   Resolution: Fixed
 Assignee: stack
Fix Version/s: 2.0.0

> Add note on how scanner caching has changed since 0.98 to refguid
> -
>
> Key: HBASE-16986
> URL: https://issues.apache.org/jira/browse/HBASE-16986
> Project: HBase
>  Issue Type: Sub-task
>  Components: documentation
>Reporter: stack
>Assignee: stack
>Priority: Minor
> Fix For: 2.0.0
>
> Attachments: 16986.txt
>
>
> Add note on how scanner caching config changed from 0.98 to the refguide (see 
> parent issue for discussion but basics are we used to have default of 100 but 
> not have unlimited as default)



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

[jira] [Created] (HBASE-16986) Add note on how scanner caching has changed since 0.98 to refguid

2016-11-01 Thread stack (JIRA) 
stack created HBASE-16986:
-

 Summary: Add note on how scanner caching has changed since 0.98 to 
refguid
 Key: HBASE-16986
 URL: https://issues.apache.org/jira/browse/HBASE-16986
 Project: HBase
  Issue Type: Sub-task
  Components: documentation
Reporter: stack
Priority: Minor


Add note on how scanner caching config changed from 0.98 to the refguide (see 
parent issue for discussion but basics are we used to have default of 100 but 
not have unlimited as default)



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

Successful: HBase Generate Website

2016-11-01 Thread Apache Jenkins Server 
Build status: Successful

If successful, the website and docs have been generated. To update the live 
site, follow the instructions below. If failed, skip to the bottom of this 
email.

Use the following commands to download the patch and apply it to a clean branch 
based on origin/asf-site. If you prefer to keep the hbase-site repo around 
permanently, you can skip the clone step.

  git clone https://git-wip-us.apache.org/repos/asf/hbase-site.git

  cd hbase-site
  wget -O- 
https://builds.apache.org/job/hbase_generate_website/395/artifact/website.patch.zip
 | funzip > 681b7da19698ab31aa7ed9dfa0754803c23da53a.patch
  git fetch
  git checkout -b asf-site-681b7da19698ab31aa7ed9dfa0754803c23da53a 
origin/asf-site
  git am --whitespace=fix 681b7da19698ab31aa7ed9dfa0754803c23da53a.patch

At this point, you can preview the changes by opening index.html or any of the 
other HTML pages in your local 
asf-site-681b7da19698ab31aa7ed9dfa0754803c23da53a branch.

There are lots of spurious changes, such as timestamps and CSS styles in 
tables, so a generic git diff is not very useful. To see a list of files that 
have been added, deleted, renamed, changed type, or are otherwise interesting, 
use the following command:

  git diff --name-status --diff-filter=ADCRTXUB origin/asf-site

To see only files that had 100 or more lines changed:

  git diff --stat origin/asf-site | grep -E '[1-9][0-9]{2,}'

When you are satisfied, publish your changes to origin/asf-site using these 
commands:

  git commit --allow-empty -m "Empty commit" # to work around a current ASF 
INFRA bug
  git push origin asf-site-681b7da19698ab31aa7ed9dfa0754803c23da53a:asf-site
  git checkout asf-site
  git branch -D asf-site-681b7da19698ab31aa7ed9dfa0754803c23da53a

Changes take a couple of minutes to be propagated. You can verify whether they 
have been propagated by looking at the Last Published date at the bottom of 
http://hbase.apache.org/. It should match the date in the index.html on the 
asf-site branch in Git.

As a courtesy- reply-all to this email to let other committers know you pushed 
the site.



If failed, see https://builds.apache.org/job/hbase_generate_website/395/console

[jira] [Created] (HBASE-16985) TestClusterId failed due to wrong hbase rootdir

2016-11-01 Thread Guanghao Zhang (JIRA) 
Guanghao Zhang created HBASE-16985:
--

 Summary: TestClusterId failed due to wrong hbase rootdir
 Key: HBASE-16985
 URL: https://issues.apache.org/jira/browse/HBASE-16985
 Project: HBase
  Issue Type: Bug
Reporter: Guanghao Zhang
Priority: Minor


https://builds.apache.org/job/PreCommit-HBASE-Build/4253/testReport/org.apache.hadoop.hbase.regionserver/TestClusterId/testClusterId/

{code}
java.io.IOException: Shutting down
at 
org.apache.hadoop.hbase.util.JVMClusterUtil.startup(JVMClusterUtil.java:230)
at 
org.apache.hadoop.hbase.LocalHBaseCluster.startup(LocalHBaseCluster.java:409)
at 
org.apache.hadoop.hbase.MiniHBaseCluster.init(MiniHBaseCluster.java:227)
at 
org.apache.hadoop.hbase.MiniHBaseCluster.(MiniHBaseCluster.java:96)
at 
org.apache.hadoop.hbase.HBaseTestingUtility.startMiniHBaseCluster(HBaseTestingUtility.java:1071)
at 
org.apache.hadoop.hbase.HBaseTestingUtility.startMiniHBaseCluster(HBaseTestingUtility.java:1037)
at 
org.apache.hadoop.hbase.regionserver.TestClusterId.testClusterId(TestClusterId.java:85)
{code}
The cluster can not start up because there are no active master. The active 
master can not finish initialing because the hbase:namespace region can not be 
assign. 

In TestClusterId unit test, TEST_UTIL.startMiniHBaseCluster set new hbase root 
dir. But the regionserver thread which stared first used  a different hbase 
root dir. If assign hbase:namespace region to this regionserver, the region can 
not be assigned because there are no tableinfo on wrong hbase root dir.

When regionserver report to master, it will get back some new config. But the 
FSTableDescriptors has been initialed so it's root dir didn't changed.
{code}
if (LOG.isDebugEnabled()) {
LOG.info("Config from master: " + key + "=" + value);
}
{code} 
I thought FSTableDescriptors need update the rootdir when regionserver get 
report from master.

The master branch has same problem, too. But the balancer always assign 
hbase:namesapce region to master. So this unit test can passed on master branch.



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

[jira] [Resolved] (HBASE-16608) Introducing the ability to merge ImmutableSegments without copy-compaction or SQM usage

2016-11-01 Thread Anastasia Braginsky (JIRA) 

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

Anastasia Braginsky resolved HBASE-16608.
-
Resolution: Fixed

> Introducing the ability to merge ImmutableSegments without copy-compaction or 
> SQM usage
> ---
>
> Key: HBASE-16608
> URL: https://issues.apache.org/jira/browse/HBASE-16608
> Project: HBase
>  Issue Type: Sub-task
>Affects Versions: 2.0.0
>Reporter: Anastasia Braginsky
>Assignee: Anastasia Braginsky
> Fix For: 2.0.0
>
> Attachments: HBASE-16417-V02.patch, HBASE-16417-V04.patch, 
> HBASE-16417-V06.patch, HBASE-16417-V07.patch, HBASE-16417-V08.patch, 
> HBASE-16417-V10.patch, HBASE-16608-Final.patch, HBASE-16608-Final.patch, 
> HBASE-16608-V01.patch, HBASE-16608-V03.patch, HBASE-16608-V04.patch, 
> HBASE-16608-V08.patch, HBASE-16608-V09.patch, HBASE-16608-V09.patch
>
>




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

[jira] [Created] (HBASE-16984) Implement getScanner

2016-11-01 Thread Duo Zhang (JIRA) 
Duo Zhang created HBASE-16984:
-

 Summary: Implement getScanner
 Key: HBASE-16984
 URL: https://issues.apache.org/jira/browse/HBASE-16984
 Project: HBase
  Issue Type: Sub-task
  Components: Client
Affects Versions: 2.0.0
Reporter: Duo Zhang
Assignee: Duo Zhang
 Fix For: 2.0.0


It will just return the old ResultScanner and work like the 
AsyncPrefetchClientScanner. I think we still need this as we can not do time 
consuming work in the ScanObserver introduced in HBASE-16838.



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

[jira] [Resolved] (HBASE-16747) Track memstore data size and heap overhead separately

2016-11-01 Thread Anoop Sam John (JIRA) 

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

Anoop Sam John resolved HBASE-16747.

Resolution: Fixed

> Track memstore data size and heap overhead separately 
> --
>
> Key: HBASE-16747
> URL: https://issues.apache.org/jira/browse/HBASE-16747
> Project: HBase
>  Issue Type: Sub-task
>  Components: regionserver
>Reporter: Anoop Sam John
>Assignee: Anoop Sam John
> Fix For: 2.0.0
>
> Attachments: HBASE-16747.patch, HBASE-16747.patch, 
> HBASE-16747_V2.patch, HBASE-16747_V2.patch, HBASE-16747_V3.patch, 
> HBASE-16747_V3.patch, HBASE-16747_V3.patch, HBASE-16747_V4.patch, 
> HBASE-16747_WIP.patch, HBASE-16747_addendum.patch
>
>
> We track the memstore size in 3 places.
> 1. Global at RS level in RegionServerAccounting. This tracks all memstore's 
> size and used to calculate whether forced flushes needed because of global 
> heap pressure
> 2. At region level in HRegion. This is sum of sizes of all memstores within 
> this region. This is used to decide whether region reaches flush size (128 MB)
> 3. Segment level. This tracks the in memory flush/compaction decisions.
> All these use the Cell's heap size which include the data bytes# as well as 
> Cell object heap overhead.  Also we include the overhead because of addition 
> of Cells into Segment's data structures (Like CSLM).
> Once we have off heap memstore, we will keep the cell data bytes in off heap 
> area. So we can not track both data size and heap overhead as one entity. We 
> need to separate them and track.
> Proposal here is to track both cell data size and heap overhead separately at 
> global accounting layer.  As of now we have only on heap memstore. So the 
> global memstore boundary checks will consider both (adds up and check against 
> global max memstore size)
> Track cell data size alone (This can be on heap or off heap) in region level. 
>  Region flushes use cell data size alone for the region flush decision. A 
> user configuring 128 MB as flush size, normally he will expect to get a 128MB 
> data flush size. But as we were including the heap overhead also, once the 
> flush happens, the actual data size getting flushed is way behind this 128 
> MB.  Now with this change we will behave more like what a user thinks.
> Segment level in memory flush/compaction also considers cell data size alone. 
>  But we will need to track the heap overhead also. (Once the in memory flush 
> or normal flush happens, we will have to adjust both cell data size and heap 
> overhead)



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