Mailing-List: contact dev-help@accumulo.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@accumulo.apache.org
Received-SPF: pass (athena.apache.org: local policy includes SPF record at
 spf.trusted-forwarder.org)
MIME-Version: 1.0
In-Reply-To: 
 <CANndRmJ2-kXLV3K_1O=v3K3wLq-EVmnVjpn-+fGWcXjUZdMa+w@mail.gmail.com>
References: <530BEB7F.9040802@gmail.com>
	<CAGUtCHrHGb4_rhUkcjSf9iwvyaiz1W50fz9yELtQM3jobJZ2KA@mail.gmail.com>
	<CAPMpPc4ftrtTe59HeUJ+fD0zysUKjx+3HG5Jf6RyAXhtM5FQYw@mail.gmail.com>
	<CADczPYQWAHdD5AcAffumGuVt+y44=RspKR_nFBPp4ib1XsG9=Q@mail.gmail.com>
	<530D2387.3050201@gmail.com>
	<CAL5zq9Yu5wwHz=EVCXTzwFbavNvpUu+9k1oy9SkC9hpMsbyyig@mail.gmail.com>
	<CAPMpPc6Dpo2XAQb8SJbkgN4o-pNi3pQ8hRcPOpyz_M0uD1eYWg@mail.gmail.com>
	<CANndRmKziL4LCCzo_X9OnaeVFsX_mG-ts0E8n0fKo9uA1cVO=A@mail.gmail.com>
	<53347BFA.8020106@gmail.com>
	<CANndRmJ2-kXLV3K_1O=v3K3wLq-EVmnVjpn-+fGWcXjUZdMa+w@mail.gmail.com>
Date: Fri, 28 Mar 2014 10:47:21 -0400
Message-ID: 
 <CAGUtCHoV27m1amhjxDbp4vgpebiyQwn6m8WntXf7WiZno4x+Ow@mail.gmail.com>
Subject: Re: [VOTE] Apache Accumulo 1.5.1-RC3
From: Keith Turner <keith@deenlo.com>
To: Accumulo Dev List <dev@accumulo.apache.org>
Content-Type: multipart/alternative; boundary=047d7b3435c071906504f5abc70f

--047d7b3435c071906504f5abc70f
Content-Type: text/plain; charset=ISO-8859-1

You could use listSplits() and then tablet locator

http://accumulo.apache.org/1.4/apidocs/org/apache/accumulo/core/client/impl/TabletLocator.html


On Fri, Mar 28, 2014 at 9:49 AM, Donald Miner <dminer@clearedgeit.com>wrote:

> I'm starting to dig around for a workaround and figured someone might be
> able to help me right away.
>
> In digging deeper, we were using RangeInputSplit because it gave us the
> splits AND the locations. We use the locations for some data locality
> placing in our distributed application. listSplits only gives us splits.
>
> Is there an easy way to get both of these pieces of information together?
>
>
> On Thu, Mar 27, 2014 at 3:28 PM, Josh Elser <josh.elser@gmail.com> wrote:
>
> > Ack, sorry about that, Don.
> >
> > We probably should have been more strict about that. It's tough to make a
> > call about a public class that someone *might* be using.
> >
> >
> > On 3/27/14, 12:26 PM, Donald Miner wrote:
> >
> >> Sorry to necro this thread, just wanted to throw my 2 cents in.
> >>
> >> We had some user code referencing this code directly and our application
> >> no
> >> longer works in 1.5.1. Just found out today when installing on 1.5.1. In
> >> retrospect, we should have been using .listSplits from TableOperatons,
> but
> >> instead we were using the RangeInputSplit method to get the splits for a
> >> table.
> >>
> >> I guess since we probably shouldn't have been doing that, I don't know
> if
> >> that's a case for this not being deleted without going to deprecated...
> >> but
> >> we did have a nasty surprise and a deprecation warning would have been
> >> nice.
> >>
> >> -d
> >>
> >>
> >> On Tue, Feb 25, 2014 at 11:33 PM, Adam Fuchs <afuchs@apache.org> wrote:
> >>
> >>  I'll buy that the RangeInputSplit is probably not referenced directly
> in
> >>> user code. In this case it's probably not a big enough change to delay
> >>> the
> >>> release.
> >>>
> >>> Adam
> >>>   On Feb 25, 2014 6:19 PM, "Christopher" <ctubbsii@apache.org> wrote:
> >>>
> >>>  I don't know that this inner class used for M/R should be considered
> >>>> public API... nor do I imagine it will cause compatibility problems if
> >>>> users aren't referencing it in their code (which there's no reason to
> >>>> expect them to). I don't know if anybody is subclassing
> >>>> RangeInputSplit, but I'd suspect that it's an acceptable risk.
> >>>> Re-adding an inner class that subclasses the now external one may be a
> >>>> good workaround. I don't think this would require recompilation for
> >>>> runtime compatibility, but if it does, I think that's probably
> >>>> acceptable.
> >>>>
> >>>> --
> >>>> Christopher L Tubbs II
> >>>> http://gravatar.com/ctubbsii
> >>>>
> >>>>
> >>>> On Tue, Feb 25, 2014 at 6:13 PM, Josh Elser <josh.elser@gmail.com>
> >>>>
> >>> wrote:
> >>>
> >>>> I haven't checked what would happen. If you subclassed the
> >>>>>
> >>>> RangeInputSplit,
> >>>>
> >>>>> it's rather likely that you'd need a recompilation.
> >>>>>
> >>>>>
> >>>>> On 2/25/14, 5:59 PM, John Vines wrote:
> >>>>>
> >>>>>>
> >>>>>> Will it? Clients don't interact with that code at all directly.
> >>>>>>
> >>>>>>
> >>>>>> On Tue, Feb 25, 2014 at 5:57 PM, Adam Fuchs <afuchs@apache.org>
> >>>>>>
> >>>>> wrote:
> >>>
> >>>>
> >>>>>>  Thanks for running that checker, Keith. Should we not be worried
> >>>>>>>
> >>>>>> about
> >>>
> >>>>  the
> >>>>>>> removal of InputFormatBase.RangeInputSplit? If I read correctly
> this
> >>>>>>>
> >>>>>> will
> >>>>
> >>>>> break both binary (runtime) compatibility and code (compile-time)
> >>>>>>> compatibility. Can somebody make an argument for why this is not a
> >>>>>>> problem
> >>>>>>> in a minor release with no previous deprecation?
> >>>>>>>
> >>>>>>> Is there a quick way to fix this, like by subclassing the
> >>>>>>> org.apache.accumulo.core.client.mapred.RangeInputSplit in a
> >>>>>>> o.a.a.c.c.mapred.InputFormatBase.RangeInputSplit that we mark as
> >>>>>>> deprecated?
> >>>>>>>
> >>>>>>> Adam
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>> On Tue, Feb 25, 2014 at 5:17 PM, Keith Turner <keith@deenlo.com>
> >>>>>>>
> >>>>>> wrote:
> >>>>
> >>>>>
> >>>>>>>  I ran a utility [1] to analyze API diffs [2] between 1.5.0 and
> >>>>>>>> 1.5.1-RC3.
> >>>>>>>> The configs I used are the two xml files in the parent [3] of the
> >>>>>>>> report.
> >>>>>>>> I think the diff looks ok.  I used jars from 1.5.0 and 1.5.1-RC3
> >>>>>>>> bin.tar.gz.
> >>>>>>>>
> >>>>>>>> [1] :
> >>>>>>>>
> >>>>>>> http://ispras.linuxbase.org/index.php/Java_API_Compliance_Checker
> >>>>
> >>>>>  [2] :
> >>>>>>>>
> >>>>>>>>  http://people.apache.org/~kturner/1.5.0_to_1.5.1-RC3/
> >>>> compat_report.html
> >>>>
> >>>>>  [3] : http://people.apache.org/~kturner/1.5.0_to_1.5.1-RC3/
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>> On Mon, Feb 24, 2014 at 8:01 PM, Josh Elser <josh.elser@gmail.com
> >
> >>>>>>>>
> >>>>>>>
> >>>>>>> wrote:
> >>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>  All,
> >>>>>>>>>
> >>>>>>>>> Please consider the following candidate as Apache Accumulo 1.5.1
> --
> >>>>>>>>>
> >>>>>>>> now
> >>>>
> >>>>>  with 100% more CHANGES changes.
> >>>>>>>>>
> >>>>>>>>> Git artifacts: The staging repository was built from the tag
> >>>>>>>>>
> >>>>>>>>
> >>>>>>> "1.5.1-rc3"
> >>>>>>>
> >>>>>>>>
> >>>>>>>>> (3478f71a).
> >>>>>>>>>
> >>>>>>>>> Maven Staging Repo:
> >>>>>>>>>
> >>>>>>>>
> >>>>>>> https://repository.apache.org/content/repositories/
> >>>>>>>
> >>>>>>>>
> >>>>>>>>> orgapacheaccumulo-1002
> >>>>>>>>>
> >>>>>>>>> Source tarball:
> http://repository.apache.org/content/repositories/
> >>>>>>>>> orgapacheaccumulo-1002/org/apache/accumulo/accumulo/1.5.
> >>>>>>>>> 1/accumulo-1.5.1-src.tar.gz
> >>>>>>>>>
> >>>>>>>>> Binary tarball:
> http://repository.apache.org/content/repositories/
> >>>>>>>>> orgapacheaccumulo-1002/org/apache/accumulo/accumulo/1.5.
> >>>>>>>>> 1/accumulo-1.5.1-bin.tar.gz
> >>>>>>>>>
> >>>>>>>>> Changes since 1.5.1-RC2: ACCUMULO-2324, ACCUMULO-2361,
> >>>>>>>>>
> >>>>>>>> ACCUMULO-2369,
> >>>
> >>>>  ACCUMULO-2378, ACCUMULO-2379, ACCUMULO-2380, ACCUMULO-2385,
> >>>>>>>>>
> >>>>>>>>
> >>>>>>>> ACCUMULO-2387,
> >>>>>>>>
> >>>>>>>>>
> >>>>>>>>> ACCUMULO-2390
> >>>>>>>>>
> >>>>>>>>> Keys: http://www.apache.org/dist/accumulo/KEYS
> >>>>>>>>>
> >>>>>>>>> Final CHANGES:
> >>>>>>>>>
> >>>>>>>>
> >>>>>>> https://git-wip-us.apache.org/repos/asf?p=accumulo.git;a=
> >>>>>>>
> >>>>>>>>
> >>>>>>>>> blob_plain;f=CHANGES;hb=3478f71ae888f8d73aaa93837319a6dbb4ba0c8a
> >>>>>>>>>
> >>>>>>>>> Testing: Unit test and auto-tests passed successfully. Ran a
> short
> >>>>>>>>>
> >>>>>>>>
> >>>>>>>> (~2hrs)
> >>>>>>>>
> >>>>>>>>>
> >>>>>>>>> CI on 6 node installation. Ran a brief (~1hr) CI test on one
> >>>>>>>>>
> >>>>>>>> machine
> >>>
> >>>>
> >>>>>>> with
> >>>>>>>
> >>>>>>>>
> >>>>>>>>> the newly-released Hadoop-2.3.0. Built from src tarball, and
> >>>>>>>>>
> >>>>>>>> verified
> >>>
> >>>>  functionality with bin tarball.
> >>>>>>>>>
> >>>>>>>>> Since there are very minor changes compared to 1.5.1-RC2, this
> vote
> >>>>>>>>>
> >>>>>>>>
> >>>>>>> will
> >>>>>>>
> >>>>>>>>
> >>>>>>>>> be open for the next 72 hours (2/28/2014 0100 UTC).
> >>>>>>>>>
> >>>>>>>>> Upon successful completion of this vote, a 1.5.1 gpg-signed Git
> tag
> >>>>>>>>>
> >>>>>>>>
> >>>>>>> will
> >>>>>>>
> >>>>>>>>
> >>>>>>>>> be created from 3478f71a and the above staging repository will be
> >>>>>>>>>
> >>>>>>>>
> >>>>>>>> promoted.
> >>>>>>>>
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>> - Josh
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>
> >>>>>>>
> >>>>>>
> >>>>>
> >>>>
> >>>
> >>
> >>
> >>
>
>
> --
>
> Donald Miner
> Chief Technology Officer
> ClearEdge IT Solutions, LLC
> Cell: 443 799 7807
> www.clearedgeit.com
>

--047d7b3435c071906504f5abc70f--