Be warned, TabletLocator isn't considered part of the public API and can change suddenly between releases.
On Fri, Mar 28, 2014 at 10:47 AM, Keith Turner <[email protected]> wrote: > 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 <[email protected] > >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 <[email protected]> > 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 <[email protected]> > 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" <[email protected]> > 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 <[email protected]> > > >>>> > > >>> 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 <[email protected]> > > >>>>>> > > >>>>> 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 <[email protected]> > > >>>>>>> > > >>>>>> 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 < > [email protected] > > > > > >>>>>>>> > > >>>>>>> > > >>>>>>> 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 > > >
