Nice work, Aditya.
Looks like the hbase-native-client profile requires gradle ?
[exec] Error: Could not find or load main class
org.gradle.wrapper.GradleWrapperMain
Will take a look at your patch.
Cheers
On Fri, Jul 18, 2014 at 3:08 PM, Aditya <adityakish...@gmail.com> wrote:
> As requested, I have attached a combined patch to the umbrella JIRA
> <https://issues.apache.org/jira/browse/HBASE-1015> and submitted it to
> jenkins.
>
> Would be great if someone could take a look and provide feedback.
>
> Regards,
> aditya...
>
>
> On Wed, Jul 9, 2014 at 7:05 PM, Aditya <adityakish...@gmail.com> wrote:
>
> > I was hoping to get some initial comments before attaching patches for
> the
> > build boat.
> >
> > I have broken the entire code into 5 patch sets, layered in a sequnce,
> > each focusing on a particular area (public headers/JNI
> > implementation/Examples+unit test, etc) for the ease of review.
> >
> > https://reviews.apache.org/r/23175/
> > https://reviews.apache.org/r/23176/
> > https://reviews.apache.org/r/23177/
> > https://reviews.apache.org/r/23178/
> > https://reviews.apache.org/r/23179/
> >
> > These are also available as a sequence of patches as the pull request
> > <https://github.com/apache/hbase/pull/1>.
> >
> > Only the last patch hooks everything to the HBase build process
> > (optionally) and hence I was thinking of squashing these separate patches
> > into a single patch to be submitted for build.
> >
> >
> > On Wed, Jul 9, 2014 at 11:32 AM, Nick Dimiduk <ndimi...@gmail.com>
> wrote:
> >
> >> This ticket has only open subtasks, ie nothing in 'patch available'. I
> >> assume you mean HBASE-10168. We'll see about getting you some reviews,
> but
> >> you should also go about formatting the patch for buildbot. Also, since
> >> your 3 reviews are individually 100+k, you should consider breaking them
> >> into three separate tickets.
> >>
> >> my 2¢
> >> -n
> >>
> >>
> >> On Mon, Jul 7, 2014 at 12:01 PM, Aditya <adityakish...@gmail.com>
> wrote:
> >>
> >>> Sorry about that.
> >>>
> >>> Here is the umbrella JIRA
> >>> https://issues.apache.org/jira/browse/HBASE-1015
> >>>
> >>>
> >>> On Mon, Jul 7, 2014 at 10:05 AM, Nick Dimiduk <ndimi...@gmail.com>
> >>> wrote:
> >>>
> >>>> Would you mind including the JIRA numbers along with the request?
> >>>>
> >>>> Thanks,
> >>>> Nick
> >>>>
> >>>>
> >>>> On Mon, Jul 7, 2014 at 9:52 AM, Aditya <adityakish...@gmail.com>
> wrote:
> >>>>
> >>>>> Do we want to have the C APIs part of 1.0.0 release. I had posted few
> >>>>> patches and a set of review request sometime last week.
> >>>>>
> >>>>>
> >>>>> On Fri, Jul 4, 2014 at 1:21 AM, Enis Söztutar <enis....@gmail.com>
> >>>>> wrote:
> >>>>>
> >>>>> > On Thu, Jul 3, 2014 at 4:41 PM, Mikhail Antonov <
> >>>>> olorinb...@gmail.com>
> >>>>> > wrote:
> >>>>> >
> >>>>> > > Moved ZK watcher & listener subtask out of scope HBASE-10909.
> Enis
> >>>>> - with
> >>>>> > > that, I guess HBASE-10909 can be marked in branch-1?
> >>>>> > >
> >>>>> >
> >>>>> > Sounds good.
> >>>>> >
> >>>>> >
> >>>>> > >
> >>>>> > > HBASE-11464 - this is the jira where I'll capture tasks to
> >>>>> abstract hbase
> >>>>> > > client from ZK (mostly it would be post-1.0 work).
> >>>>> > >
> >>>>> >
> >>>>> > Not sure whether we can make it fully backwards compatible with 1.0
> >>>>> > clients. I guess we will see when the patches are done.
> >>>>> >
> >>>>> >
> >>>>> > >
> >>>>> > > Thanks,
> >>>>> > > Mikhail
> >>>>> > >
> >>>>> > >
> >>>>> > > 2014-07-03 12:52 GMT-07:00 Stack <st...@duboce.net>:
> >>>>> > >
> >>>>> > > > On Thu, Jul 3, 2014 at 12:25 PM, Mikhail Antonov <
> >>>>> olorinb...@gmail.com
> >>>>> > >
> >>>>> > > > wrote:
> >>>>> > > >
> >>>>> > > > > Guys,
> >>>>> > > > >
> >>>>> > > > > getting back to ZK abstraction work w.r.t. release 1.0 and
> >>>>> > thereafter,
> >>>>> > > > some
> >>>>> > > > > status update. So as we're getting closer to complete
> >>>>> HBASE-10909, it
> >>>>> > > > looks
> >>>>> > > > > like the steps may be like this:
> >>>>> > > > >
> >>>>> > > > > - there are 2 subtasks out there not closed yet, one of
> which
> >>>>> is
> >>>>> > about
> >>>>> > > > log
> >>>>> > > > > splitting (and Sergey S has submitted a patch for review),
> >>>>> another is
> >>>>> > > > > abstraction of ZK watcher (this is what I've been working on
> >>>>> in the
> >>>>> > > > > background; but after sketching the patch it seems like
> >>>>> without being
> >>>>> > > > able
> >>>>> > > > > to modify the control flows and some changes in the module
> >>>>> structure,
> >>>>> > > > it'd
> >>>>> > > > > be a lot of scaffolding code not really simplifying current
> >>>>> code). So
> >>>>> > > I'd
> >>>>> > > > > propose to descope abstraction of ZK watcher jira
> >>>>> (HBASE-11073),
> >>>>> > > namely:
> >>>>> > > > > convert it to top-level JIRA and continue to work on it
> >>>>> separately;
> >>>>> > > > rename
> >>>>> > > > > HBASE-10909 to "ZK abstraction: phase 1", and mark it as
> >>>>> closed as
> >>>>> > soon
> >>>>> > > > as
> >>>>> > > > > log splitting jira is completed. This way HBASE-10909 fits to
> >>>>> > branch-1.
> >>>>> > > > >
> >>>>> > > >
> >>>>> > > > Sounds good to me.
> >>>>> > > >
> >>>>> > > >
> >>>>> > > > > - secondly, in the discussion to the CatalogTracker patch,
> we
> >>>>> > started
> >>>>> > > > > talking about modifying client to not know about ZK, but
> >>>>> rather keep
> >>>>> > > the
> >>>>> > > > > location of current masters and talk to them using RPC calls.
> >>>>> This
> >>>>> > work
> >>>>> > > > can
> >>>>> > > > > not go into branch-1, as it involves invasive changes in
> client
> >>>>> > > including
> >>>>> > > > > new RPC. As I understand the branching schema now, those
> >>>>> changes can
> >>>>> > go
> >>>>> > > > to
> >>>>> > > > > master branch, we just don't merge them to branch-1, and
> >>>>> depending on
> >>>>> > > > their
> >>>>> > > > > completeness we can pull them to 1.1 release or so.
> >>>>> > > > >
> >>>>> > > >
> >>>>> > > > You have it right Mikhail.
> >>>>> > > >
> >>>>> > > > St.Ack
> >>>>> > > >
> >>>>> > >
> >>>>> > >
> >>>>> > >
> >>>>> > > --
> >>>>> > > Thanks,
> >>>>> > > Michael Antonov
> >>>>> > >
> >>>>> >
> >>>>>
> >>>>
> >>>>
> >>>
> >>
> >
>
