accumulo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From John Vines <vi...@apache.org>
Subject Re: [VOTE] Apache Accumulo 1.5.1-RC3
Date Fri, 28 Mar 2014 15:36:25 GMT
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 <keith@deenlo.com> 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 <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
> >
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message