HBASE 2.0

Hello, All, It is time to discuss about the schedule of HBase 2.0 release. HBase 2.0 release is a big major release. When we release 1.0, we had 0.99 as dev preview/beta release. We should do something similar for the 2.0 release. Matteo and I talked about this. We think about that we need

Re: HBASE 2.0

w.r.t. feature, there is also: HBASE-15968 MVCC-sensitive semantics of versions On Mon, Oct 3, 2016 at 3:27 PM, Stephen Jiang wrote: > Hello, All, > > It is time to discuss about the schedule of HBase 2.0 release. HBase 2.0 > release is a big major release. When we release 1.0,

Re: HBASE 2.0

ns for the upcoming releases and start to use those tags. Matteo or Stephen can change the existing issues with tag 2.0.0 to be 2.0.0-alpha1 instead. Enis On Mon, Oct 3, 2016 at 3:27 PM, Stephen Jiang wrote: > Hello, All, > > It is time to discuss about the schedule of HBase 2.0

Re: HBASE 2.0

rote: > Hello, All, > > It is time to discuss about the schedule of HBase 2.0 release. HBase 2.0 > release is a big major release. When we release 1.0, we had 0.99 as dev > preview/beta release. We should do something similar for the 2.0 release. > > Matteo and I talked abo

Re: HBASE 2.0

er inserted too before the > release of hbase-2.0.0 (I know Matteo probably ruled it out as too far out > to land in time but I'm the eternal optimist...) > > Thanks, > M > > > > > > On Mon, Oct 3, 2016 at 3:27 PM, Stephen Jiang > wrote: > > > Hello

Re: HBASE 2.0

> It is time to discuss about the schedule of HBase 2.0 release. HBase 2.0 > release is a big major release. When we release 1.0, we had 0.99 as dev > preview/beta release. We should do something similar for the 2.0 release. > > Matteo and I talked about this. We think about

Re: HBASE 2.0

; > to land in time but I'm the eternal optimist...) > > > > > > Thanks, > > > M > > > > > > > > > > > > > > > > > > On Mon, Oct 3, 2016 at 3:27 PM, Stephen Jiang > > > > wrote: > > > &g

Re: HBASE 2.0

base-2.0.0 (I know Matteo probably ruled it out as too far > out > > to land in time but I'm the eternal optimist...) > > > > Thanks, > > M > > > > > > > > > > > > On Mon, Oct 3, 2016 at 3:27 PM, Stephen Jiang > > wrote: > > > > &g

Re: HBASE 2.0

On Tue, Oct 4, 2016 at 12:00 PM, Andrew Purtell wrote: >> Currently, we are aware of the following on-going new features for 2.0: > new Assignment Manager, backup/restore, off-heap, protobuff 3, Hybrid > Logical Clock, and maybe AsyncRegion / C++ client). > > For what it is worth, depending on th

Re: HBASE 2.0

Thanks for bring this up Stephen, great to know a detailed plan for 2.0, have been expecting that for some time. :-) w.r.t new features, I hope we could also include the below two: 1. AsyncTable (HBASE-15921) 2. Netty-based RpcServer (HBASE-15756 bring up the idea and we'll open new JIRA to make i

Hadoop 3.x profile working for hbase 2.0 [Re: HBASE 2.0]

l, > > It is time to discuss about the schedule of HBase 2.0 release. HBase 2.0 > release is a big major release. When we release 1.0, we had 0.99 as dev > preview/beta release. We should do something similar for the 2.0 release. > > Matteo and I talked about this. We think a

HBASE 2.0 release progress

Hello, fellow HBASE developers, We are making progress towards HBASE 2.0 releases. I am using the following queries to search for on-going HBASE 2.0 feature work items (project = HBase AND (fixVersion = 2.0.0 OR affectedVersion = 2.0.0) AND resolution is EMPTY AND (issuetype != Bug AND issuetype

Planning for HBase 2.0

Hey folks, my list for 2.0 looks quite full, but I'm probably missing something. main point is probably that we want to be rolling upgradable. a direct rolling upgrade may be not easy, so the option is to do it in two phases. more or less: "after all the machines are on the new version trigger an

Re: Hadoop 3.x profile working for hbase 2.0 [Re: HBASE 2.0]

at 3:27 PM, Stephen Jiang > wrote: > > > Hello, All, > > > > It is time to discuss about the schedule of HBase 2.0 release. HBase 2.0 > > release is a big major release. When we release 1.0, we had 0.99 as dev > > preview/beta release. We should do

Re: Hadoop 3.x profile working for hbase 2.0 [Re: HBASE 2.0]

week or two. > > > > Other related issues that are nice to have but wouldn't block an hbase > > alpha include: > > 1) having no always failing unit tests against hadoop3 (HBASE-6581) > > > > Thoughts? > > Jon. > > > > On Mon, Oct 3, 2016 at

Re: Hadoop 3.x profile working for hbase 2.0 [Re: HBASE 2.0]

up in jenkins so that we can gain insight and burn > down > > > unit tests failures against hadoop3. > > > > > > These items have a good chance of landing in the next week or two. > > > > > > Other related issues that are nice to have but wouldn'

Re: Hadoop 3.x profile working for hbase 2.0 [Re: HBASE 2.0]

setup in jenkins so that we can gain insight and burn > > down > > > > unit tests failures against hadoop3. > > > > > > > > These items have a good chance of landing in the next week or two. > > > > > > > > Other related issues that

Re: Hadoop 3.x profile working for hbase 2.0 [Re: HBASE 2.0]

compile checks against a hadoop 3.x (HBASE-16733) > > > > > 3) get 'mvn test install -Dskiptests' to succeed without licensing > > > issues > > > > > (HBASE-16712) > > > > > 4) Have a job setup in jenkins so that we can gain insight and burn &g

Re: HBASE 2.0 release progress

of JIRAs. These JIRAs haven't been touched for about a year. Looks like they can be moved to next release if there is no active work going on. Cheers On Fri, Nov 11, 2016 at 5:15 PM, Stephen Jiang wrote: > Hello, fellow HBASE developers, > > We are making progress towards HBASE 2.

Re: HBASE 2.0 release progress

n't been touched for about a year. > > Looks like they can be moved to next release if there is no active work > going on. > > Cheers > > > > On Fri, Nov 11, 2016 at 5:15 PM, Stephen Jiang > wrote: > > > Hello, fellow HBASE developers, > > > > We are ma

Re: HBASE 2.0 release progress

Thanks for the writeup Stephen. See below. On Fri, Nov 11, 2016 at 5:15 PM, Stephen Jiang wrote: > Hello, fellow HBASE developers, > > We are making progress towards HBASE 2.0 releases. I am using the > following queries to search for on-going HBASE 2.0 feature work items > (

Re: HBASE 2.0 release progress

ck wrote: > Thanks for the writeup Stephen. > > See below. > > On Fri, Nov 11, 2016 at 5:15 PM, Stephen Jiang > wrote: > > > Hello, fellow HBASE developers, > > > > We are making progress towards HBASE 2.0 releases. I am using the > > following queries

Re: HBASE 2.0 release progress

t; > > > On Fri, Nov 11, 2016 at 5:15 PM, Stephen Jiang > > wrote: > > > > > Hello, fellow HBASE developers, > > > > > > We are making progress towards HBASE 2.0 releases. I am using the > > > following queries to search for on-going HBASE 2.0 feature

Re: HBASE 2.0 release progress

> > > > > Thanks for the writeup Stephen. > > > > > > See below. > > > > > > On Fri, Nov 11, 2016 at 5:15 PM, Stephen Jiang < > syuanjiang...@gmail.com> > > > wrote: > > > > > > > Hello, fellow HBASE develope

Re: HBASE 2.0 release progress

7 PM, Stack > > wrote: > > > > > Thanks for the writeup Stephen. > > > > > > See below. > > > > > > On Fri, Nov 11, 2016 at 5:15 PM, Stephen Jiang < > syuanjiang...@gmail.com > > > > wrote: > > > > > > > H

Re: HBASE 2.0 release progress

t;> > up-to-date state of offheaping? >> > - Logical clock - at this point is it more like a nice to have feature >> > than "need to be done before 2.0"? What are the features blocked or >> > affected by lack thereof? >> > >> > -Mikhail

Re: HBASE 2.0 release progress

t; wrote: > > > Hello, fellow HBASE developers, > > > > We are making progress towards HBASE 2.0 releases. I am using the > > following queries to search for on-going HBASE 2.0 feature work items > > (project = HBase AND (fixVersion = 2.0.0 OR affectedVersion = 2.

Re: HBASE 2.0 release progress

Late to respond to this but I'd like to get "Split Meta" HBASE-11165 into HBase 2.0 as well. We've been running with a version of it internally. I'll start putting up patches soon. On Friday, November 11, 2016 5:15 PM, Stephen Jiang wrote: Hello, fellow

Re: HBASE 2.0 release progress

o-date state of offheaping? >> >  -  Logical clock - at this point is it more like a nice to have feature >> > than "need to be done before 2.0"? What are the features blocked or >> > affected by lack thereof? >> > >> > -Mikhail >> &g

Re: HBASE 2.0 release progress

t;>>> perf/stability testing? Are you guys running tips of master branch >>> through >>>> ITBLL setup? >>>> - Anyone (Ram, Anoop?) wants to post a high-level writeup on the >>> current >>>> up-to-date state of offheaping? >>>> - Lo

Re: HBASE 2.0 release progress

r. > On Nov 21, 2016, at 5:59 PM, Francis Liu wrote: > > Late to respond to this but I'd like to get "Split Meta" HBASE-11165 into > HBase 2.0 as well. We've been running with a version of it internally. I'll > start putting up patches soon. > >

Re: HBASE 2.0 release progress

riteup on the >>> current >>>> up-to-date state of offheaping? >>>>  -  Logical clock - at this point is it more like a nice to have feature >>>> than "need to be done before 2.0"? What are the features blocked or >>>> affected by lack ther

Re: HBASE 2.0 release progress

>>>> As I'm reading through the list, here're some high-level questions I > >>> have: > >>>> > >>>> - Regarding the work on new AssignmentManager - any notes on > >>>> perf/stability testing? Are you guys running tips

Re: HBASE 2.0 release progress

l questions I > >>> have: > >>>> > >>>>  -  Regarding the work on new AssignmentManager - any notes on > >>>> perf/stability testing? Are you guys running tips of master branch > >>> through > >>>> ITBLL setup? >

Re: Planning for HBase 2.0

Design for the following is being finalized: HBASE-13153 enable bulkload to support replication Do you think it should be included ? Cheers On Mon, Sep 7, 2015 at 8:42 PM, Matteo Bertozzi wrote: > Hey folks, > > my list for 2.0 looks quite full, but I'm probably missing something. > > main poi

Re: Planning for HBase 2.0

on my list there are mainly major changes. HBASE-13153 seems small enough that may also be considered for a branch-1. it will take at least 3 months to have a branch-2, I don't want this thread to end up pointing out all minor jiras. so, my rule is: if it is not a major architectural change and pe

Re: Planning for HBase 2.0

I filed HBASE-14379 as an umbrella to collect work for a "Replication V2" effort. The umbrella has a summary of principles and goals from the discussion at the recent dev meetup and a survey of open replication related issues. On Mon, Sep 7, 2015 at 9:42 PM, Matteo Bertozzi wrote: > on my list

Re: Planning for HBase 2.0

This is a nice list already Matteo! +1, I think rolling upgrade should be supported -- said another way, we need an *extremely* strong argument to justify NOT supporting rolling upgrade. Your above approach sounds reasonable, and should allow for early abort of the upgrade (i.e., before all machin

Re: Planning for HBase 2.0

bq. rolling upgrade should be supported +1 Has anyone done preliminary testing where we stand (master branch) in this regard ? Cheers On Tue, Sep 8, 2015 at 2:28 PM, Nick Dimiduk wrote: > This is a nice list already Matteo! > > +1, I think rolling upgrade should be supported -- said another w

Re: Planning for HBase 2.0

I see the branch-1 as 0.94 or 0.98 when 2.0 will be out. I'm pretty sure some people will not move even if we are rolling upgradable. also for the first period there will be some skepticism with all the core changes. so, i'm pretty sure branch-1 will stay alive for some time. Matteo On Tue, Sep

Re: Planning for HBase 2.0

Agree. I think branch-1 will live for a long time (just like 0.98.x). My suggestion is that we should suspend more minor releases in 1.x line once 2.0 is released. Only patch releases in 1.x after 2.0 release is out. Thanks Stephen On Tue, Sep 8, 2015 at 2:41 PM, Matteo Bertozzi wrote: > I s

Re: Planning for HBase 2.0

Hi There, Will users have the option to stick with on-heap if they prefer once HBASE-11425 is implemented? On Mon, Sep 7, 2015 at 11:42 PM, Matteo Bertozzi wrote: > Hey folks, > > my list for 2.0 looks quite full, but I'm probably missing something. > > main point is probably that we want to

Re: Planning for HBase 2.0

HBASE-11425 do end to end off heap path when off heap mode bucket cache is been used. If u dont prefer off heap and not use bucket cache off heap there wont be any diff. It will be on heap path. Anoop On Monday, October 5, 2015, Biju N wrote: > Hi There, > Will users have the option to stic

Re: Planning for HBase 2.0

Thanks Anoop. To summarize for my understanding, - If off heap is used for bucket cache then after 11425, LRU & Bucket cache will be off heap. - If oh heap is used for bucket cache then everything will be on heap. Is this correct? If so I am assuming that the property "bucketcache.ioengine" will

Friday Trivia number: HBASE 2.0 JIRAs

I did some search on how big HBASE 2.0 is. Here is some interesting numbers: (1). How many resolved as fixed JIRAs are for 2.0 only? As of today morning (10/14), we have *875*! I used the following query: " project = HBase AND fixVersion = 2.0.0 AND fixVersion not in releasedVersions(

Ruby shell versions for HBase 2.0

ults to Ruby 1.9 but can be run in Ruby 1.8 mode. There are some implementation details outstanding, but I'm hoping that ticket can work out such that it can land in branch-1. For HBase 2.0, I'd like us to plan for a little farther out in the future than just updating to Ruby 1.9 (though th

[DISCUSS] hbase-2.0.x requires jdk8

Any objection? jdk7 is dead, EOL'd. You all good w/ this? St.Ack

Re: Friday Trivia number: HBASE 2.0 JIRAs

Jiang wrote: > I did some search on how big HBASE 2.0 is. Here is some interesting > numbers: > > (1). How many resolved as fixed JIRAs are for 2.0 only? > As of today morning (10/14), we have *875*! > > I used the following query: " > project = HBase AND fixVer

Re: Friday Trivia number: HBASE 2.0 JIRAs

branch-1.3 > > Hopefully stabilizing branch-2 doesn't take that long. > > Cheers > > On Fri, Oct 14, 2016 at 12:04 PM, Stephen Jiang > wrote: > >> I did some search on how big HBASE 2.0 is. Here is some interesting >> numbers: >> >> (1). H

Re: Ruby shell versions for HBase 2.0

7 so that our shell > can work on PPC systems[1]. That version of JRuby defaults to Ruby 1.9 but > can be run in Ruby 1.8 mode. There are some implementation details > outstanding, but I'm hoping that ticket can work out such that it can land > in branch-1. > > For HBase 2.

Re: Ruby shell versions for HBase 2.0

Nice writeup Sean. Yeah, +1 to new jruby in hbase 2.0. We'd need to be careful license is still amenable and hopefully jruby 9k will be slimmer than jruby 1.7+. But if we are going to do a significant shell refactor for hbase 2.0, should we consider doing something more radical; e.g. a new

Re: Ruby shell versions for HBase 2.0

version of JRuby defaults to Ruby 1.9 > but > > can be run in Ruby 1.8 mode. There are some implementation details > > outstanding, but I'm hoping that ticket can work out such that it can > land > > in branch-1. > > > > For HBase 2.0, I'd like us to plan

Re: Ruby shell versions for HBase 2.0

+1 to new jruby in hbase 2.0. We'd need to be careful license is > still amenable and hopefully jruby 9k will be slimmer than jruby 1.7+. > > But if we are going to do a significant shell refactor for hbase 2.0, > should we consider doing something more radical; e.g. a new shell?

Re: Ruby shell versions for HBase 2.0

ower shell" via irb) together in 2.0 and aim for default in 3.0. -- Sean On May 13, 2015 12:19 PM, "Stack" wrote: > Nice writeup Sean. > > Yeah, +1 to new jruby in hbase 2.0. We'd need to be careful license is > still amenable and hopefully jruby 9k will be slimmer

Re: Ruby shell versions for HBase 2.0

rote: > > > Nice writeup Sean. > > > > Yeah, +1 to new jruby in hbase 2.0. We'd need to be careful license is > > still amenable and hopefully jruby 9k will be slimmer than jruby 1.7+. > > > > But if we are going to do a significant shell refactor for hbase

Re: Ruby shell versions for HBase 2.0

On May 13, 2015 12:06 PM, "Michael Segel" wrote: > > So… > Silly question… > Do you really need to worry about backward’s compatibility? > > How many people have customized HBaseShell ? > > What are the common customizations and if you port HBase shell, how much work would filter through to the cu

Re: Ruby shell versions for HBase 2.0

;power shell" via irb) together in 2.0 and aim for default in 3.0. > > > > -- > > Sean > > On May 13, 2015 12:19 PM, "Stack" wrote: > > > > > Nice writeup Sean. > > > > > > Yeah, +1 to new jruby in hbase 2.0. We'd need

Re: Ruby shell versions for HBase 2.0

out a SQL shell? /me ducks > and runs for cover > > > On Wed, May 13, 2015 at 10:19 AM, Stack wrote: > > > Nice writeup Sean. > > > > Yeah, +1 to new jruby in hbase 2.0. We'd need to be careful license is > > still amenable and hopefully jruby 9k will be

Re: Ruby shell versions for HBase 2.0

Agreed on these points, Sean. Having used both, I think both approaches have their value and their drawbacks. The ruby shell is _wonderful_ from having a full programming language to interact with. Accumulo's shell would force you to use your standard unix-toolbelt if you want to do any extra

Re: Ruby shell versions for HBase 2.0

> > > I figured given time we could get a preview "user shell" (rather than > > > "power shell" via irb) together in 2.0 and aim for default in 3.0. > > > > > > -- > > > Sean > > > On May 13, 2015 12:19 PM, "Stack&quo

Re: Ruby shell versions for HBase 2.0

S > > engine (Java 8+) instead, that would have worked well also. > > > > And if we're talking about new shells, what about a SQL shell? /me ducks > > and runs for cover > > > > > > On Wed, May 13, 2015 at 10:19 AM, Stack wrote: > > > > >

Re: Ruby shell versions for HBase 2.0

Hmmm. So if we move to a different tech, the modifications / customizations people have done are going to be useless. If we upgrade to a new version of JRuby, some scripts may not have issues, others may have some , and a third group would have major rewrites. The interesting / downside to J

Re: Ruby shell versions for HBase 2.0

e that rely on customizations. I figured given time we could get a preview "user shell" (rather than "power shell" via irb) together in 2.0 and aim for default in 3.0. -- Sean On May 13, 2015 12:19 PM, "Stack" wrote: Nice writeup Sean. Yeah, +1 to new jruby in h

Re: Ruby shell versions for HBase 2.0

hell superior? >>>> >>>> Is it scriptable? >>>> >>>> >>>> On Wed, May 13, 2015 at 10:28 AM, Sean Busbey >>>> >>> wrote: >>> >>>> I would love to rip out the JRuby shell entirely and make something >>

Re: Ruby shell versions for HBase 2.0

gt;>> * adding custom commands requires knowing java >>>> >>>> -- >>>> Sean >>>> On May 13, 2015 12:31 PM, "Andrew Purtell" wrote: >>>> >>>> Why is the Accumulo shell superior? >>>>> >>>>&

Re: Ruby shell versions for HBase 2.0

gt; >>> -- > >>> Sean > >>> On May 13, 2015 12:31 PM, "Andrew Purtell" > wrote: > >>> > >>> Why is the Accumulo shell superior? > >>>> > >>>> Is it scriptable? > >>>> > >>&g

Re: Ruby shell versions for HBase 2.0

ean > >>> On May 13, 2015 12:31 PM, "Andrew Purtell" > wrote: > >>> > >>> Why is the Accumulo shell superior? > >>>> > >>>> Is it scriptable? > >>>> > >>>> > >>>> On Wed, May

Re: Ruby shell versions for HBase 2.0

shell) > > >>> > > >>> Cons > > >>> > > >>> * adding custom commands requires knowing java > > >>> > > >>> -- > > >>> Sean > > >>> On May 13, 2015 12:31 PM, "Andrew Purtell" > &

Re: [DISCUSS] hbase-2.0.x requires jdk8

we'll need to get a feature into yetus that can change multijdk settings by branch, presuming that change will result in us either taking on jdk8-only dependencies or direct use of jdk8-only features. On Thu, Apr 7, 2016 at 9:18 PM, Stack wrote: > Any objection? > > jdk7 is dead, EOL'd. > > You a

Re: [DISCUSS] hbase-2.0.x requires jdk8

Is there a YETUS issue for this Sean or should I file one? St.Ack On Thu, Apr 7, 2016 at 9:21 PM, Sean Busbey wrote: > we'll need to get a feature into yetus that can change multijdk > settings by branch, presuming that change will result in us either > taking on jdk8-only dependencies or direct

Re: [DISCUSS] hbase-2.0.x requires jdk8

As a side benefit, only testing one jdk would seriously speed up test runs. +1 On Thu, Apr 7, 2016 at 10:12 PM, Stack wrote: > Is there a YETUS issue for this Sean or should I file one? > St.Ack > > On Thu, Apr 7, 2016 at 9:21 PM, Sean Busbey wrote: > > > we'll need to get a feature into yetus

Re: [DISCUSS] hbase-2.0.x requires jdk8

+1 on jdk8 only. Bunch of code could be refactored with jdk8's new features, new classes and new methods. For example, most 'get->putIfAbsent->checkAndCleanUp' and 'get->lock->get again->put->unlock' can be replaced by computeIfAbsent. 2016-04-08 16:43 GMT+08:00 Elliott Clark : > As a side benefi

Re: [DISCUSS] hbase-2.0.x requires jdk8

I don't think there's an issue yet. On Apr 8, 2016 00:12, "Stack" wrote: > Is there a YETUS issue for this Sean or should I file one? > St.Ack > > On Thu, Apr 7, 2016 at 9:21 PM, Sean Busbey wrote: > > > we'll need to get a feature into yetus that can change multijdk > > settings by branch, pres

Re: [DISCUSS] hbase-2.0.x requires jdk8

I don't think it'll actually speed up tests much. In precommit we only check one jdk for unit tests and in postcommit we do them in parallel. On Apr 8, 2016 03:44, "Elliott Clark" wrote: > As a side benefit, only testing one jdk would seriously speed up test runs. > > +1 > > On Thu, Apr 7, 2016 a

Re: [DISCUSS] hbase-2.0.x requires jdk8

+1 On Thursday, April 7, 2016, Stack wrote: > Any objection? > > jdk7 is dead, EOL'd. > > You all good w/ this? > > St.Ack >

Re: [DISCUSS] hbase-2.0.x requires jdk8

+1 -- Cloudera, Inc. On Fri, Apr 8, 2016 at 8:36 AM, Nick Dimiduk wrote: > +1 > > On Thursday, April 7, 2016, Stack wrote: > > > Any objection? > > > > jdk7 is dead, EOL'd. > > > > You all good w/ this? > > > > St.Ack > > >

Re: [DISCUSS] hbase-2.0.x requires jdk8

+1 -Mikhail On Fri, Apr 8, 2016 at 10:18 AM, Esteban Gutierrez wrote: > +1 > > -- > Cloudera, Inc. > > > On Fri, Apr 8, 2016 at 8:36 AM, Nick Dimiduk wrote: > > > +1 > > > > On Thursday, April 7, 2016, Stack wrote: > > > > > Any objection? > > > > > > jdk7 is dead, EOL'd. > > > > > > You all

Re: [DISCUSS] hbase-2.0.x requires jdk8

I filed https://issues.apache.org/jira/browse/YETUS-369 (though I hate filing stuff w/o putting up a patch... maybe I'll get to doing one!) St.Ack On Fri, Apr 8, 2016 at 6:04 AM, Sean Busbey wrote: > I don't think there's an issue yet. > On Apr 8, 2016 00:12, "Stack" wrote: > > > Is there a YET

Re: [DISCUSS] hbase-2.0.x requires jdk8

+1 Best Regards, Yu On 9 April 2016 at 02:13, Stack wrote: > I filed https://issues.apache.org/jira/browse/YETUS-369 (though I hate > filing stuff w/o putting up a patch... maybe I'll get to doing one!) > St.Ack > > On Fri, Apr 8, 2016 at 6:04 AM, Sean Busbey wrote: > > > I don't think there's

Re: [DISCUSS] hbase-2.0.x requires jdk8

Thanks all for chiming in. I filed HBASE-15624 Move master branch/hbase-2.0.0 to jdk-8 only to act on the decision made here. St.Ack On Fri, Apr 8, 2016 at 11:30 AM, Yu Li wrote: > +1 > > Best Regards, > Yu > > On 9 April 2016 at 02:13, Stack wrote: > > > I filed https://issues.apache.org/jira

Re: [DISCUSS] hbase-2.0.x requires jdk8

unsubscribe On Thu, Apr 7, 2016 at 9:18 PM, Stack wrote: > Any objection? > > jdk7 is dead, EOL'd. > > You all good w/ this? > > St.Ack >

Re: [DISCUSS] hbase-2.0.x requires jdk8

+1 On Mon, Apr 11, 2016 at 4:30 AM, Gerry Morales wrote: > unsubscribe > > On Thu, Apr 7, 2016 at 9:18 PM, Stack wrote: > > > Any objection? > > > > jdk7 is dead, EOL'd. > > > > You all good w/ this? > > > > St.Ack > > >

Re: [DISCUSS] hbase-2.0.x requires jdk8

Good idea and +1. Thanks Stephen On Sun, Apr 10, 2016 at 7:12 PM, ramkrishna vasudevan < ramkrishna.s.vasude...@gmail.com> wrote: > +1 > > On Mon, Apr 11, 2016 at 4:30 AM, Gerry Morales > wrote: > > > unsubscribe > > > > On Thu, Apr 7, 2016 at 9:18 PM, Stack wrote: > > > > > Any objection? >

[ANNOUNCE] Asynchronous client is available in HBase 2.0

Dear all, Asynchronous client aims to provide the ability to access HBase asynchronously. You can obtain an AsyncConnection from ConnectionFactory, and then get an asynchronous table instance (for DML operations) or an asynchronous admin instance (for DDL operations) from it to access HBase. For t

Re: [ANNOUNCE] Asynchronous client is available in HBase 2.0

Very sweet Guanghao. Thanks for all the hard work (you, Duo and all who contributed to the async work). When you think we should move the sync client to be on top of the async chassis? Thanks, St.Ack P.S. It looks like you updated its status in this doc, https://docs.google.com/document/d/1WCsVl

Re: [ANNOUNCE] Asynchronous client is available in HBase 2.0

I filed an issue HBASE-18334 to remove the old sync implementation. I think we can do it in 3.0 and keep sync logic in branch-2? Of course we can also remove it in 2.1 or higher 2.x branch but if we remove it since 2.0 it may be a little radical

Re: [ANNOUNCE] Asynchronous client is available in HBase 2.0

On Fri, Jul 21, 2017 at 10:21 AM, Phil Yang wrote: > I filed an issue HBASE-18334 > to remove the old sync > implementation. I think we can do it in 3.0 and keep sync logic in > branch-2? Of course we can also remove it in 2.1 or higher 2.x bran

Re: [ANNOUNCE] Asynchronous client is available in HBase 2.0

This is exciting! Thanks so much for this hard work. On Fri, Jul 21, 2017 at 2:21 AM, Phil Yang wrote: > I filed an issue HBASE-18334 > to remove the old sync > implementation. I think we can do it in 3.0 and keep sync logic in > branch-2? Of c

Re: [ANNOUNCE] Asynchronous client is available in HBase 2.0

@stack, sorry for reply late, sir. As HBASE-16388 said, the client threads may be blocked by only one slow region server. But a better solution for this problem is to use async hbase client. And there are many reasons to make a region server slow,

Re: [ANNOUNCE] Asynchronous client is available in HBase 2.0

The current pe tool, both our pe and the YCSB, are all designed for sync client, so usually there will be no performance boost since in these tests we can only use async client in a sync way. And if we do some simple modifications, such as do not wait reply and keep sending requests, no doubt async

[jira] [Created] (HBASE-20656) Validate pre-2.0 coprocessors against HBase 2.0+

Balazs Meszaros created HBASE-20656: --- Summary: Validate pre-2.0 coprocessors against HBase 2.0+ Key: HBASE-20656 URL: https://issues.apache.org/jira/browse/HBASE-20656 Project: HBase Issue

[jira] [Created] (HBASE-11515) Rewrite HBase Ref Guide for HBase 2.0

Misty Stanley-Jones created HBASE-11515: --- Summary: Rewrite HBase Ref Guide for HBase 2.0 Key: HBASE-11515 URL: https://issues.apache.org/jira/browse/HBASE-11515 Project: HBase Issue

[VOTE] Backup/Restore feature for HBase 2.0, vote closing 3/11/2017

Hello, HBase folks For your consideration today is Backup/Restore feature for Apache HBAse 2.0. Backup code is available as a mega patch in HBASE-14123 (v61), applies cleanly to the current master, all test PASS, patch has no other issues. The patch has gone through numerous rounds of code

[DISCUSS] is hbase-spark integration going to make it into HBase 2.0

Hi Folks! Our Stack recently gave an updated timeline on HBase 2.0 related releases [1] that has us quickly approaching feature freeze for beta releases. Previously, we had a great discussion on what it takes for our hbase-spark integration to be ready for release[2]. (see the summary in the

[jira] [Created] (HBASE-20369) Document incompatibilities between HBase 1.1.2 and HBase 2.0

Thiriguna Bharat Rao created HBASE-20369: Summary: Document incompatibilities between HBase 1.1.2 and HBase 2.0 Key: HBASE-20369 URL: https://issues.apache.org/jira/browse/HBASE-20369 Project

Re: [VOTE] Backup/Restore feature for HBase 2.0, vote closing 3/11/2017

March 11th is on weekend. Do you want to give people who haven't looked at the mega patch in depth some more time ? Cheers On Wed, Mar 8, 2017 at 1:32 PM, Vladimir Rodionov wrote: > Hello, HBase folks > > For your consideration today is Backup/Restore feature for Apache HBAse &

Re: [VOTE] Backup/Restore feature for HBase 2.0, vote closing 3/11/2017

, etc. Enis On Wed, Mar 8, 2017 at 1:32 PM, Vladimir Rodionov wrote: > Hello, HBase folks > > For your consideration today is Backup/Restore feature for Apache HBAse > 2.0. > Backup code is available as a mega patch in HBASE-14123 (v61), applies > cleanly to the current master, all

Re: [VOTE] Backup/Restore feature for HBase 2.0, vote closing 3/11/2017

odionov > wrote: > > > Hello, HBase folks > > > > For your consideration today is Backup/Restore feature for Apache HBAse > > 2.0. > > Backup code is available as a mega patch in HBASE-14123 (v61), applies > > cleanly to the current master, all test PASS,

Re: [VOTE] Backup/Restore feature for HBase 2.0, vote closing 3/11/2017

merge now so that > development can continue in master, and there is more exposure for testing, > etc. > > Enis > > On Wed, Mar 8, 2017 at 1:32 PM, Vladimir Rodionov > wrote: > > > Hello, HBase folks > > > > For your consideration today is Backup/Restore fea

Re: [VOTE] Backup/Restore feature for HBase 2.0, vote closing 3/11/2017

th >> some more time ? >> >> Cheers >> >> On Wed, Mar 8, 2017 at 1:32 PM, Vladimir Rodionov > > >> wrote: >> >> > Hello, HBase folks >> > >> > For your consideration today is Backup/Restore feature for Apache HBAse >> &

  1   2   >