You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@accumulo.apache.org by Josh Elser <jo...@gmail.com> on 2014/02/25 02:01:51 UTC
[VOTE] Apache Accumulo 1.5.1-RC3
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
Re: [VOTE] Apache Accumulo 1.5.1-RC3
Posted by Mike Drob <ma...@cloudera.com>.
I went ahead and marked 1.5.1 as released in JIRA. Team effort!
On Fri, Feb 28, 2014 at 2:18 PM, Christopher <ct...@apache.org> wrote:
> If you can go ahead and promote the staging repo and create the signed
> tag in git, somebody else can upload the artifacts to the dist repo,
> so they can be distributed to the mirrors before we create the release
> announcement/release notes and update the website.
>
> --
> Christopher L Tubbs II
> http://gravatar.com/ctubbsii
>
>
> On Fri, Feb 28, 2014 at 11:32 AM, Josh Elser <jo...@gmail.com> wrote:
> > Alright guys and gals. Given Keith's last comment, I think we can call
> this.
> >
> > The VOTE for rc3 as Apache Accumulo 1.5.1 passes with 4 +1s and nothing
> > else.
> >
> > I'm out of town this week so this won't be promoted until late next week.
> > Please consider things you would want listed in some release notes and
> let
> > me know. I'll promote the artifacts when I return and get some release
> > notes written.
> >
> > Thank you everyone who made the time to be a part of this process.
> > On Feb 28, 2014 10:35 AM, "Eric Newton" <er...@gmail.com> wrote:
> >
> >> Just tried it. It worked fine.
> >>
> >> -Eric
> >>
> >>
> >>
> >> On Fri, Feb 28, 2014 at 10:20 AM, Keith Turner <ke...@deenlo.com>
> wrote:
> >>
> >> > One thing I would like to do but have not had time is to create an
> >> Accumulo
> >> > maven project that depends on 1.5.1, configure maven to use the
> staging
> >> > repo, and build and run the test. Has anyone else tried this?
> >> >
> >> >
> >> > On Mon, Feb 24, 2014 at 8:01 PM, Josh Elser <jo...@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
> >> > >
> >> >
> >>
>
Re: [VOTE] Apache Accumulo 1.5.1-RC3
Posted by Christopher <ct...@apache.org>.
If you can go ahead and promote the staging repo and create the signed
tag in git, somebody else can upload the artifacts to the dist repo,
so they can be distributed to the mirrors before we create the release
announcement/release notes and update the website.
--
Christopher L Tubbs II
http://gravatar.com/ctubbsii
On Fri, Feb 28, 2014 at 11:32 AM, Josh Elser <jo...@gmail.com> wrote:
> Alright guys and gals. Given Keith's last comment, I think we can call this.
>
> The VOTE for rc3 as Apache Accumulo 1.5.1 passes with 4 +1s and nothing
> else.
>
> I'm out of town this week so this won't be promoted until late next week.
> Please consider things you would want listed in some release notes and let
> me know. I'll promote the artifacts when I return and get some release
> notes written.
>
> Thank you everyone who made the time to be a part of this process.
> On Feb 28, 2014 10:35 AM, "Eric Newton" <er...@gmail.com> wrote:
>
>> Just tried it. It worked fine.
>>
>> -Eric
>>
>>
>>
>> On Fri, Feb 28, 2014 at 10:20 AM, Keith Turner <ke...@deenlo.com> wrote:
>>
>> > One thing I would like to do but have not had time is to create an
>> Accumulo
>> > maven project that depends on 1.5.1, configure maven to use the staging
>> > repo, and build and run the test. Has anyone else tried this?
>> >
>> >
>> > On Mon, Feb 24, 2014 at 8:01 PM, Josh Elser <jo...@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
>> > >
>> >
>>
Re: [VOTE] Apache Accumulo 1.5.1-RC3
Posted by Josh Elser <jo...@gmail.com>.
Alright guys and gals. Given Keith's last comment, I think we can call this.
The VOTE for rc3 as Apache Accumulo 1.5.1 passes with 4 +1s and nothing
else.
I'm out of town this week so this won't be promoted until late next week.
Please consider things you would want listed in some release notes and let
me know. I'll promote the artifacts when I return and get some release
notes written.
Thank you everyone who made the time to be a part of this process.
On Feb 28, 2014 10:35 AM, "Eric Newton" <er...@gmail.com> wrote:
> Just tried it. It worked fine.
>
> -Eric
>
>
>
> On Fri, Feb 28, 2014 at 10:20 AM, Keith Turner <ke...@deenlo.com> wrote:
>
> > One thing I would like to do but have not had time is to create an
> Accumulo
> > maven project that depends on 1.5.1, configure maven to use the staging
> > repo, and build and run the test. Has anyone else tried this?
> >
> >
> > On Mon, Feb 24, 2014 at 8:01 PM, Josh Elser <jo...@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
> > >
> >
>
Re: [VOTE] Apache Accumulo 1.5.1-RC3
Posted by Eric Newton <er...@gmail.com>.
Just tried it. It worked fine.
-Eric
On Fri, Feb 28, 2014 at 10:20 AM, Keith Turner <ke...@deenlo.com> wrote:
> One thing I would like to do but have not had time is to create an Accumulo
> maven project that depends on 1.5.1, configure maven to use the staging
> repo, and build and run the test. Has anyone else tried this?
>
>
> On Mon, Feb 24, 2014 at 8:01 PM, Josh Elser <jo...@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
> >
>
Re: [VOTE] Apache Accumulo 1.5.1-RC3
Posted by Keith Turner <ke...@deenlo.com>.
One thing I would like to do but have not had time is to create an Accumulo
maven project that depends on 1.5.1, configure maven to use the staging
repo, and build and run the test. Has anyone else tried this?
On Mon, Feb 24, 2014 at 8:01 PM, Josh Elser <jo...@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
>
Re: [VOTE] Apache Accumulo 1.5.1-RC3
Posted by Sean Busbey <bu...@cloudera.com>.
I thought I noticed some other incompatible changes between 1.5.0 and 1.5.1
when I was looking for things to backport to 1.4 for Hadoop 2 support.
Shall we open a blocker ticket and fix things for 1.5.2, aiming for release
shortly after 1.6.0?
On Thu, Mar 27, 2014 at 2:28 PM, Josh Elser <jo...@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 <af...@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" <ct...@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 <jo...@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 <af...@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 <ke...@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 <jo...@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
>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>>
>>
>>
Re: [VOTE] Apache Accumulo 1.5.1-RC3
Posted by John Vines <vi...@apache.org>.
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 <ke...@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 <jo...@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 <af...@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" <ct...@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 <jo...@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 <af...@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 <ke...@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
> >
>
Re: [VOTE] Apache Accumulo 1.5.1-RC3
Posted by Keith Turner <ke...@deenlo.com>.
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 <dm...@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 <jo...@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 <af...@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" <ct...@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 <jo...@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 <af...@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 <ke...@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
>
Re: [VOTE] Apache Accumulo 1.5.1-RC3
Posted by Donald Miner <dm...@clearedgeit.com>.
Ah, if all I need to do is change the class name to
org.apache.accumulo.core.client.mapreduce.RangeInputSplit .... I feel kind
of dumb. I didn't realize it was renamed. I can do that.
On a separate note (maybe more appropriate for the user list) but keeping
in here for continuity sake:
We have an application that has daemons running on every Hadoop node.
When we kick off a query in our application, this is what happens:
- we figure out what splits there are on the table we want and what
tablet servers those splits are on
- we tell our application's daemons to do a range scan across the
tablets that are colocated on the same node (1 range scan per tablet)
- daemon processes data
- etc.
So, we need both the split information and the locality information to get
this to work right.
Is there a better way to do this? It seems like teasing out information
from an inputformat class seems like kind of a hack. We could use
TabletLocator, but that's not in the public API either? Is there a right
way for a client to get locality information?
-d
On Fri, Mar 28, 2014 at 1:12 PM, Sean Busbey <bu...@cloudera.com>wrote:
> The README is already clear that everything under those packages is
> included, with the exception of the impl pacakge.
>
> In my reading, that means all Classes and Interfaces in any package under
> the client package, and everything in those classes that is at either
> public and protected access.
>
> I guess this should be included in our pending discussion about
> compatibility across versions?
>
>
> On Fri, Mar 28, 2014 at 12:02 PM, Josh Elser <jo...@gmail.com> wrote:
>
> > Also, reading back through this chain, it was state as unclear as to
> > whether or not an inner class of a class in the public API is also,
> itself,
> > in the public API.
> >
> > This should also be clarified in our definition of public API in the
> > README. Obviously, Don and Sean both agree that it should be. The
> > discussion of those on the vote didn't. Doesn't really matter to me
> either
> > way.
> >
> >
> > On 3/28/14, 9:50 AM, Josh Elser wrote:
> >
> >> Ah, I missed the recursiveness of the o.a.a.c.c.
> >>
> >> But, like I mentioned in the other message, I don't think binary compat
> >> was achieved, but the package name, constructors, and methods existing
> >> in 1.5.0 were maintained AFAIK. Are we asserting binary compat here as
> >> well?
> >>
> >> I'm trying to understand if we actually didn't follow our own rules, or
> >> if the expectations of the community are exceeding the rules we have for
> >> ourselves. I think we're in the latter right now.
> >>
> >> On 3/28/14, 9:41 AM, Sean Busbey wrote:
> >>
> >>> According to the definition of the public API in version 1.5.0,
> >>> RangeInputSplit is a part of the public API.
> >>>
> >>>
> >>> On Fri, Mar 28, 2014 at 11:26 AM, Josh Elser <jo...@gmail.com>
> >>> wrote:
> >>>
> >>> Devil's advocate: RangeInputSplit isn't part of the public API
> >>>> either, so
> >>>> it comes with the same risks that TabletLocator would.
> >>>>
> >>>> It sounds more like the definition of "public api" should be expanded
> to
> >>>> prevent this in future cases. I need to look at what exactly broke
> >>>> for Don.
> >>>>
> >>>>
> >>>> On 3/28/14, 9:12 AM, Sean Busbey wrote:
> >>>>
> >>>> Don,
> >>>>>
> >>>>> If you can file a jira with some example code that covers what parts
> of
> >>>>> the
> >>>>> 1.5.0 API you hit, I can see if I can a patch to get you working.
> >>>>>
> >>>>> That would give you a patch you could apply on top of 1.5.1 now and
> >>>>> when
> >>>>> 1.5.2 comes out it would correctly support the API.
> >>>>>
> >>>>> -Sean
> >>>>>
> >>>>> On Fri, Mar 28, 2014 at 8: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 <jo...@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 <af...@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" <ct...@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
> >>>>>>>>>>>>> <ke...@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=3478f71ae888f8d73aaa93837319a6
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>>> dbb4ba0c8a
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>> 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
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>
> >>>
>
--
Donald Miner
Chief Technology Officer
ClearEdge IT Solutions, LLC
Cell: 443 799 7807
www.clearedgeit.com
Re: [VOTE] Apache Accumulo 1.5.1-RC3
Posted by Sean Busbey <bu...@cloudera.com>.
Filed as ACCUMULO-2590
https://issues.apache.org/jira/browse/ACCUMULO-2590
On Fri, Mar 28, 2014 at 2:56 PM, Josh Elser <jo...@gmail.com> wrote:
> Can someone make a 1.6 ticket to clarify this confusion in the README?
>
> There is undeniable confusion to date but it doesn't seem like anyone minds
> including public nested classes either. I'd have to scan over the public
> members of these classes to make sure we don't inadvertantly advertise
> something we don't intend to.
> On Mar 28, 2014 12:17 PM, "Bill Havanki" <bh...@clouderagovt.com>
> wrote:
>
> > That was my interpretation as well.
> >
> >
> > On Fri, Mar 28, 2014 at 3:13 PM, Mike Drob <ma...@cloudera.com> wrote:
> >
> > > Public members, including inner classes, of public classes seem like
> they
> > > are de facto Public API.
> > >
> > >
> > > On Fri, Mar 28, 2014 at 3:11 PM, Josh Elser <jo...@gmail.com>
> > wrote:
> > >
> > > > Yes. This is exactly what was discussed earlier in this thread.
> > > > On Mar 28, 2014 10:35 AM, "Christopher" <ct...@apache.org> wrote:
> > > >
> > > > > That README was probably written without consideration of the
> > > > > implication for inner-classes. There is a strict interpretation,
> yes,
> > > > > but the intent is certainly not clear.
> > > > >
> > > > > --
> > > > > Christopher L Tubbs II
> > > > > http://gravatar.com/ctubbsii
> > > > >
> > > > >
> > > > > On Fri, Mar 28, 2014 at 1:12 PM, Sean Busbey <
> > > busbey+lists@cloudera.com>
> > > > > wrote:
> > > > > > The README is already clear that everything under those packages
> is
> > > > > > included, with the exception of the impl pacakge.
> > > > > >
> > > > > > In my reading, that means all Classes and Interfaces in any
> package
> > > > under
> > > > > > the client package, and everything in those classes that is at
> > either
> > > > > > public and protected access.
> > > > > >
> > > > > > I guess this should be included in our pending discussion about
> > > > > > compatibility across versions?
> > > > > >
> > > > > >
> > > > > > On Fri, Mar 28, 2014 at 12:02 PM, Josh Elser <
> josh.elser@gmail.com
> > >
> > > > > wrote:
> > > > > >
> > > > > >> Also, reading back through this chain, it was state as unclear
> as
> > to
> > > > > >> whether or not an inner class of a class in the public API is
> > also,
> > > > > itself,
> > > > > >> in the public API.
> > > > > >>
> > > > > >> This should also be clarified in our definition of public API in
> > the
> > > > > >> README. Obviously, Don and Sean both agree that it should be.
> The
> > > > > >> discussion of those on the vote didn't. Doesn't really matter to
> > me
> > > > > either
> > > > > >> way.
> > > > > >>
> > > > > >>
> > > > > >> On 3/28/14, 9:50 AM, Josh Elser wrote:
> > > > > >>
> > > > > >>> Ah, I missed the recursiveness of the o.a.a.c.c.
> > > > > >>>
> > > > > >>> But, like I mentioned in the other message, I don't think
> binary
> > > > compat
> > > > > >>> was achieved, but the package name, constructors, and methods
> > > > existing
> > > > > >>> in 1.5.0 were maintained AFAIK. Are we asserting binary compat
> > here
> > > > as
> > > > > >>> well?
> > > > > >>>
> > > > > >>> I'm trying to understand if we actually didn't follow our own
> > > rules,
> > > > or
> > > > > >>> if the expectations of the community are exceeding the rules we
> > > have
> > > > > for
> > > > > >>> ourselves. I think we're in the latter right now.
> > > > > >>>
> > > > > >>> On 3/28/14, 9:41 AM, Sean Busbey wrote:
> > > > > >>>
> > > > > >>>> According to the definition of the public API in version
> 1.5.0,
> > > > > >>>> RangeInputSplit is a part of the public API.
> > > > > >>>>
> > > > > >>>>
> > > > > >>>> On Fri, Mar 28, 2014 at 11:26 AM, Josh Elser <
> > > josh.elser@gmail.com>
> > > > > >>>> wrote:
> > > > > >>>>
> > > > > >>>> Devil's advocate: RangeInputSplit isn't part of the public
> API
> > > > > >>>>> either, so
> > > > > >>>>> it comes with the same risks that TabletLocator would.
> > > > > >>>>>
> > > > > >>>>> It sounds more like the definition of "public api" should be
> > > > > expanded to
> > > > > >>>>> prevent this in future cases. I need to look at what exactly
> > > broke
> > > > > >>>>> for Don.
> > > > > >>>>>
> > > > > >>>>>
> > > > > >>>>> On 3/28/14, 9:12 AM, Sean Busbey wrote:
> > > > > >>>>>
> > > > > >>>>> Don,
> > > > > >>>>>>
> > > > > >>>>>> If you can file a jira with some example code that covers
> what
> > > > > parts of
> > > > > >>>>>> the
> > > > > >>>>>> 1.5.0 API you hit, I can see if I can a patch to get you
> > > working.
> > > > > >>>>>>
> > > > > >>>>>> That would give you a patch you could apply on top of 1.5.1
> > now
> > > > and
> > > > > >>>>>> when
> > > > > >>>>>> 1.5.2 comes out it would correctly support the API.
> > > > > >>>>>>
> > > > > >>>>>> -Sean
> > > > > >>>>>>
> > > > > >>>>>> On Fri, Mar 28, 2014 at 8: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
> > > > > >>>>>>>>>>>>>> <ke...@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=3478f71ae888f8d73aaa93837319a6
> > > > > >>>>>>>>>>>>>>>
> > > > > >>>>>>>>>>>>>>>> dbb4ba0c8a
> > > > > >>>>>>>>>>>>>>>>
> > > > > >>>>>>>>>>>>>>>> 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
> > > > > >>>>>>>
> > > > > >>>>>>>
> > > > > >>>>>>>
> > > > > >>>>>>
> > > > > >>>>
> > > > >
> > > >
> > >
> >
> >
> >
> > --
> > // Bill Havanki
> > // Solutions Architect, Cloudera Govt Solutions
> > // 443.686.9283
> >
>
--
Sean Busbey
Software Engineer
Cloudera, Inc.
Phone: MAN-VS-BEARD
Re: [VOTE] Apache Accumulo 1.5.1-RC3
Posted by Josh Elser <jo...@gmail.com>.
Can someone make a 1.6 ticket to clarify this confusion in the README?
There is undeniable confusion to date but it doesn't seem like anyone minds
including public nested classes either. I'd have to scan over the public
members of these classes to make sure we don't inadvertantly advertise
something we don't intend to.
On Mar 28, 2014 12:17 PM, "Bill Havanki" <bh...@clouderagovt.com> wrote:
> That was my interpretation as well.
>
>
> On Fri, Mar 28, 2014 at 3:13 PM, Mike Drob <ma...@cloudera.com> wrote:
>
> > Public members, including inner classes, of public classes seem like they
> > are de facto Public API.
> >
> >
> > On Fri, Mar 28, 2014 at 3:11 PM, Josh Elser <jo...@gmail.com>
> wrote:
> >
> > > Yes. This is exactly what was discussed earlier in this thread.
> > > On Mar 28, 2014 10:35 AM, "Christopher" <ct...@apache.org> wrote:
> > >
> > > > That README was probably written without consideration of the
> > > > implication for inner-classes. There is a strict interpretation, yes,
> > > > but the intent is certainly not clear.
> > > >
> > > > --
> > > > Christopher L Tubbs II
> > > > http://gravatar.com/ctubbsii
> > > >
> > > >
> > > > On Fri, Mar 28, 2014 at 1:12 PM, Sean Busbey <
> > busbey+lists@cloudera.com>
> > > > wrote:
> > > > > The README is already clear that everything under those packages is
> > > > > included, with the exception of the impl pacakge.
> > > > >
> > > > > In my reading, that means all Classes and Interfaces in any package
> > > under
> > > > > the client package, and everything in those classes that is at
> either
> > > > > public and protected access.
> > > > >
> > > > > I guess this should be included in our pending discussion about
> > > > > compatibility across versions?
> > > > >
> > > > >
> > > > > On Fri, Mar 28, 2014 at 12:02 PM, Josh Elser <josh.elser@gmail.com
> >
> > > > wrote:
> > > > >
> > > > >> Also, reading back through this chain, it was state as unclear as
> to
> > > > >> whether or not an inner class of a class in the public API is
> also,
> > > > itself,
> > > > >> in the public API.
> > > > >>
> > > > >> This should also be clarified in our definition of public API in
> the
> > > > >> README. Obviously, Don and Sean both agree that it should be. The
> > > > >> discussion of those on the vote didn't. Doesn't really matter to
> me
> > > > either
> > > > >> way.
> > > > >>
> > > > >>
> > > > >> On 3/28/14, 9:50 AM, Josh Elser wrote:
> > > > >>
> > > > >>> Ah, I missed the recursiveness of the o.a.a.c.c.
> > > > >>>
> > > > >>> But, like I mentioned in the other message, I don't think binary
> > > compat
> > > > >>> was achieved, but the package name, constructors, and methods
> > > existing
> > > > >>> in 1.5.0 were maintained AFAIK. Are we asserting binary compat
> here
> > > as
> > > > >>> well?
> > > > >>>
> > > > >>> I'm trying to understand if we actually didn't follow our own
> > rules,
> > > or
> > > > >>> if the expectations of the community are exceeding the rules we
> > have
> > > > for
> > > > >>> ourselves. I think we're in the latter right now.
> > > > >>>
> > > > >>> On 3/28/14, 9:41 AM, Sean Busbey wrote:
> > > > >>>
> > > > >>>> According to the definition of the public API in version 1.5.0,
> > > > >>>> RangeInputSplit is a part of the public API.
> > > > >>>>
> > > > >>>>
> > > > >>>> On Fri, Mar 28, 2014 at 11:26 AM, Josh Elser <
> > josh.elser@gmail.com>
> > > > >>>> wrote:
> > > > >>>>
> > > > >>>> Devil's advocate: RangeInputSplit isn't part of the public API
> > > > >>>>> either, so
> > > > >>>>> it comes with the same risks that TabletLocator would.
> > > > >>>>>
> > > > >>>>> It sounds more like the definition of "public api" should be
> > > > expanded to
> > > > >>>>> prevent this in future cases. I need to look at what exactly
> > broke
> > > > >>>>> for Don.
> > > > >>>>>
> > > > >>>>>
> > > > >>>>> On 3/28/14, 9:12 AM, Sean Busbey wrote:
> > > > >>>>>
> > > > >>>>> Don,
> > > > >>>>>>
> > > > >>>>>> If you can file a jira with some example code that covers what
> > > > parts of
> > > > >>>>>> the
> > > > >>>>>> 1.5.0 API you hit, I can see if I can a patch to get you
> > working.
> > > > >>>>>>
> > > > >>>>>> That would give you a patch you could apply on top of 1.5.1
> now
> > > and
> > > > >>>>>> when
> > > > >>>>>> 1.5.2 comes out it would correctly support the API.
> > > > >>>>>>
> > > > >>>>>> -Sean
> > > > >>>>>>
> > > > >>>>>> On Fri, Mar 28, 2014 at 8: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
> > > > >>>>>>>>>>>>>> <ke...@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=3478f71ae888f8d73aaa93837319a6
> > > > >>>>>>>>>>>>>>>
> > > > >>>>>>>>>>>>>>>> dbb4ba0c8a
> > > > >>>>>>>>>>>>>>>>
> > > > >>>>>>>>>>>>>>>> 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
> > > > >>>>>>>
> > > > >>>>>>>
> > > > >>>>>>>
> > > > >>>>>>
> > > > >>>>
> > > >
> > >
> >
>
>
>
> --
> // Bill Havanki
> // Solutions Architect, Cloudera Govt Solutions
> // 443.686.9283
>
Re: [VOTE] Apache Accumulo 1.5.1-RC3
Posted by Bill Havanki <bh...@clouderagovt.com>.
That was my interpretation as well.
On Fri, Mar 28, 2014 at 3:13 PM, Mike Drob <ma...@cloudera.com> wrote:
> Public members, including inner classes, of public classes seem like they
> are de facto Public API.
>
>
> On Fri, Mar 28, 2014 at 3:11 PM, Josh Elser <jo...@gmail.com> wrote:
>
> > Yes. This is exactly what was discussed earlier in this thread.
> > On Mar 28, 2014 10:35 AM, "Christopher" <ct...@apache.org> wrote:
> >
> > > That README was probably written without consideration of the
> > > implication for inner-classes. There is a strict interpretation, yes,
> > > but the intent is certainly not clear.
> > >
> > > --
> > > Christopher L Tubbs II
> > > http://gravatar.com/ctubbsii
> > >
> > >
> > > On Fri, Mar 28, 2014 at 1:12 PM, Sean Busbey <
> busbey+lists@cloudera.com>
> > > wrote:
> > > > The README is already clear that everything under those packages is
> > > > included, with the exception of the impl pacakge.
> > > >
> > > > In my reading, that means all Classes and Interfaces in any package
> > under
> > > > the client package, and everything in those classes that is at either
> > > > public and protected access.
> > > >
> > > > I guess this should be included in our pending discussion about
> > > > compatibility across versions?
> > > >
> > > >
> > > > On Fri, Mar 28, 2014 at 12:02 PM, Josh Elser <jo...@gmail.com>
> > > wrote:
> > > >
> > > >> Also, reading back through this chain, it was state as unclear as to
> > > >> whether or not an inner class of a class in the public API is also,
> > > itself,
> > > >> in the public API.
> > > >>
> > > >> This should also be clarified in our definition of public API in the
> > > >> README. Obviously, Don and Sean both agree that it should be. The
> > > >> discussion of those on the vote didn't. Doesn't really matter to me
> > > either
> > > >> way.
> > > >>
> > > >>
> > > >> On 3/28/14, 9:50 AM, Josh Elser wrote:
> > > >>
> > > >>> Ah, I missed the recursiveness of the o.a.a.c.c.
> > > >>>
> > > >>> But, like I mentioned in the other message, I don't think binary
> > compat
> > > >>> was achieved, but the package name, constructors, and methods
> > existing
> > > >>> in 1.5.0 were maintained AFAIK. Are we asserting binary compat here
> > as
> > > >>> well?
> > > >>>
> > > >>> I'm trying to understand if we actually didn't follow our own
> rules,
> > or
> > > >>> if the expectations of the community are exceeding the rules we
> have
> > > for
> > > >>> ourselves. I think we're in the latter right now.
> > > >>>
> > > >>> On 3/28/14, 9:41 AM, Sean Busbey wrote:
> > > >>>
> > > >>>> According to the definition of the public API in version 1.5.0,
> > > >>>> RangeInputSplit is a part of the public API.
> > > >>>>
> > > >>>>
> > > >>>> On Fri, Mar 28, 2014 at 11:26 AM, Josh Elser <
> josh.elser@gmail.com>
> > > >>>> wrote:
> > > >>>>
> > > >>>> Devil's advocate: RangeInputSplit isn't part of the public API
> > > >>>>> either, so
> > > >>>>> it comes with the same risks that TabletLocator would.
> > > >>>>>
> > > >>>>> It sounds more like the definition of "public api" should be
> > > expanded to
> > > >>>>> prevent this in future cases. I need to look at what exactly
> broke
> > > >>>>> for Don.
> > > >>>>>
> > > >>>>>
> > > >>>>> On 3/28/14, 9:12 AM, Sean Busbey wrote:
> > > >>>>>
> > > >>>>> Don,
> > > >>>>>>
> > > >>>>>> If you can file a jira with some example code that covers what
> > > parts of
> > > >>>>>> the
> > > >>>>>> 1.5.0 API you hit, I can see if I can a patch to get you
> working.
> > > >>>>>>
> > > >>>>>> That would give you a patch you could apply on top of 1.5.1 now
> > and
> > > >>>>>> when
> > > >>>>>> 1.5.2 comes out it would correctly support the API.
> > > >>>>>>
> > > >>>>>> -Sean
> > > >>>>>>
> > > >>>>>> On Fri, Mar 28, 2014 at 8: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
> > > >>>>>>>>>>>>>> <ke...@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=3478f71ae888f8d73aaa93837319a6
> > > >>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>> dbb4ba0c8a
> > > >>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>> 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
> > > >>>>>>>
> > > >>>>>>>
> > > >>>>>>>
> > > >>>>>>
> > > >>>>
> > >
> >
>
--
// Bill Havanki
// Solutions Architect, Cloudera Govt Solutions
// 443.686.9283
Re: [VOTE] Apache Accumulo 1.5.1-RC3
Posted by Mike Drob <ma...@cloudera.com>.
Public members, including inner classes, of public classes seem like they
are de facto Public API.
On Fri, Mar 28, 2014 at 3:11 PM, Josh Elser <jo...@gmail.com> wrote:
> Yes. This is exactly what was discussed earlier in this thread.
> On Mar 28, 2014 10:35 AM, "Christopher" <ct...@apache.org> wrote:
>
> > That README was probably written without consideration of the
> > implication for inner-classes. There is a strict interpretation, yes,
> > but the intent is certainly not clear.
> >
> > --
> > Christopher L Tubbs II
> > http://gravatar.com/ctubbsii
> >
> >
> > On Fri, Mar 28, 2014 at 1:12 PM, Sean Busbey <bu...@cloudera.com>
> > wrote:
> > > The README is already clear that everything under those packages is
> > > included, with the exception of the impl pacakge.
> > >
> > > In my reading, that means all Classes and Interfaces in any package
> under
> > > the client package, and everything in those classes that is at either
> > > public and protected access.
> > >
> > > I guess this should be included in our pending discussion about
> > > compatibility across versions?
> > >
> > >
> > > On Fri, Mar 28, 2014 at 12:02 PM, Josh Elser <jo...@gmail.com>
> > wrote:
> > >
> > >> Also, reading back through this chain, it was state as unclear as to
> > >> whether or not an inner class of a class in the public API is also,
> > itself,
> > >> in the public API.
> > >>
> > >> This should also be clarified in our definition of public API in the
> > >> README. Obviously, Don and Sean both agree that it should be. The
> > >> discussion of those on the vote didn't. Doesn't really matter to me
> > either
> > >> way.
> > >>
> > >>
> > >> On 3/28/14, 9:50 AM, Josh Elser wrote:
> > >>
> > >>> Ah, I missed the recursiveness of the o.a.a.c.c.
> > >>>
> > >>> But, like I mentioned in the other message, I don't think binary
> compat
> > >>> was achieved, but the package name, constructors, and methods
> existing
> > >>> in 1.5.0 were maintained AFAIK. Are we asserting binary compat here
> as
> > >>> well?
> > >>>
> > >>> I'm trying to understand if we actually didn't follow our own rules,
> or
> > >>> if the expectations of the community are exceeding the rules we have
> > for
> > >>> ourselves. I think we're in the latter right now.
> > >>>
> > >>> On 3/28/14, 9:41 AM, Sean Busbey wrote:
> > >>>
> > >>>> According to the definition of the public API in version 1.5.0,
> > >>>> RangeInputSplit is a part of the public API.
> > >>>>
> > >>>>
> > >>>> On Fri, Mar 28, 2014 at 11:26 AM, Josh Elser <jo...@gmail.com>
> > >>>> wrote:
> > >>>>
> > >>>> Devil's advocate: RangeInputSplit isn't part of the public API
> > >>>>> either, so
> > >>>>> it comes with the same risks that TabletLocator would.
> > >>>>>
> > >>>>> It sounds more like the definition of "public api" should be
> > expanded to
> > >>>>> prevent this in future cases. I need to look at what exactly broke
> > >>>>> for Don.
> > >>>>>
> > >>>>>
> > >>>>> On 3/28/14, 9:12 AM, Sean Busbey wrote:
> > >>>>>
> > >>>>> Don,
> > >>>>>>
> > >>>>>> If you can file a jira with some example code that covers what
> > parts of
> > >>>>>> the
> > >>>>>> 1.5.0 API you hit, I can see if I can a patch to get you working.
> > >>>>>>
> > >>>>>> That would give you a patch you could apply on top of 1.5.1 now
> and
> > >>>>>> when
> > >>>>>> 1.5.2 comes out it would correctly support the API.
> > >>>>>>
> > >>>>>> -Sean
> > >>>>>>
> > >>>>>> On Fri, Mar 28, 2014 at 8: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
> > >>>>>>>>>>>>>> <ke...@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=3478f71ae888f8d73aaa93837319a6
> > >>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>> dbb4ba0c8a
> > >>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>> 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
> > >>>>>>>
> > >>>>>>>
> > >>>>>>>
> > >>>>>>
> > >>>>
> >
>
Re: [VOTE] Apache Accumulo 1.5.1-RC3
Posted by Josh Elser <jo...@gmail.com>.
Yes. This is exactly what was discussed earlier in this thread.
On Mar 28, 2014 10:35 AM, "Christopher" <ct...@apache.org> wrote:
> That README was probably written without consideration of the
> implication for inner-classes. There is a strict interpretation, yes,
> but the intent is certainly not clear.
>
> --
> Christopher L Tubbs II
> http://gravatar.com/ctubbsii
>
>
> On Fri, Mar 28, 2014 at 1:12 PM, Sean Busbey <bu...@cloudera.com>
> wrote:
> > The README is already clear that everything under those packages is
> > included, with the exception of the impl pacakge.
> >
> > In my reading, that means all Classes and Interfaces in any package under
> > the client package, and everything in those classes that is at either
> > public and protected access.
> >
> > I guess this should be included in our pending discussion about
> > compatibility across versions?
> >
> >
> > On Fri, Mar 28, 2014 at 12:02 PM, Josh Elser <jo...@gmail.com>
> wrote:
> >
> >> Also, reading back through this chain, it was state as unclear as to
> >> whether or not an inner class of a class in the public API is also,
> itself,
> >> in the public API.
> >>
> >> This should also be clarified in our definition of public API in the
> >> README. Obviously, Don and Sean both agree that it should be. The
> >> discussion of those on the vote didn't. Doesn't really matter to me
> either
> >> way.
> >>
> >>
> >> On 3/28/14, 9:50 AM, Josh Elser wrote:
> >>
> >>> Ah, I missed the recursiveness of the o.a.a.c.c.
> >>>
> >>> But, like I mentioned in the other message, I don't think binary compat
> >>> was achieved, but the package name, constructors, and methods existing
> >>> in 1.5.0 were maintained AFAIK. Are we asserting binary compat here as
> >>> well?
> >>>
> >>> I'm trying to understand if we actually didn't follow our own rules, or
> >>> if the expectations of the community are exceeding the rules we have
> for
> >>> ourselves. I think we're in the latter right now.
> >>>
> >>> On 3/28/14, 9:41 AM, Sean Busbey wrote:
> >>>
> >>>> According to the definition of the public API in version 1.5.0,
> >>>> RangeInputSplit is a part of the public API.
> >>>>
> >>>>
> >>>> On Fri, Mar 28, 2014 at 11:26 AM, Josh Elser <jo...@gmail.com>
> >>>> wrote:
> >>>>
> >>>> Devil's advocate: RangeInputSplit isn't part of the public API
> >>>>> either, so
> >>>>> it comes with the same risks that TabletLocator would.
> >>>>>
> >>>>> It sounds more like the definition of "public api" should be
> expanded to
> >>>>> prevent this in future cases. I need to look at what exactly broke
> >>>>> for Don.
> >>>>>
> >>>>>
> >>>>> On 3/28/14, 9:12 AM, Sean Busbey wrote:
> >>>>>
> >>>>> Don,
> >>>>>>
> >>>>>> If you can file a jira with some example code that covers what
> parts of
> >>>>>> the
> >>>>>> 1.5.0 API you hit, I can see if I can a patch to get you working.
> >>>>>>
> >>>>>> That would give you a patch you could apply on top of 1.5.1 now and
> >>>>>> when
> >>>>>> 1.5.2 comes out it would correctly support the API.
> >>>>>>
> >>>>>> -Sean
> >>>>>>
> >>>>>> On Fri, Mar 28, 2014 at 8: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 <jo...@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 <af...@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
> >>>>>>>>>>>>>> <ke...@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=3478f71ae888f8d73aaa93837319a6
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>> dbb4ba0c8a
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>> 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
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>
> >>>>
>
Re: [VOTE] Apache Accumulo 1.5.1-RC3
Posted by Christopher <ct...@apache.org>.
That README was probably written without consideration of the
implication for inner-classes. There is a strict interpretation, yes,
but the intent is certainly not clear.
--
Christopher L Tubbs II
http://gravatar.com/ctubbsii
On Fri, Mar 28, 2014 at 1:12 PM, Sean Busbey <bu...@cloudera.com> wrote:
> The README is already clear that everything under those packages is
> included, with the exception of the impl pacakge.
>
> In my reading, that means all Classes and Interfaces in any package under
> the client package, and everything in those classes that is at either
> public and protected access.
>
> I guess this should be included in our pending discussion about
> compatibility across versions?
>
>
> On Fri, Mar 28, 2014 at 12:02 PM, Josh Elser <jo...@gmail.com> wrote:
>
>> Also, reading back through this chain, it was state as unclear as to
>> whether or not an inner class of a class in the public API is also, itself,
>> in the public API.
>>
>> This should also be clarified in our definition of public API in the
>> README. Obviously, Don and Sean both agree that it should be. The
>> discussion of those on the vote didn't. Doesn't really matter to me either
>> way.
>>
>>
>> On 3/28/14, 9:50 AM, Josh Elser wrote:
>>
>>> Ah, I missed the recursiveness of the o.a.a.c.c.
>>>
>>> But, like I mentioned in the other message, I don't think binary compat
>>> was achieved, but the package name, constructors, and methods existing
>>> in 1.5.0 were maintained AFAIK. Are we asserting binary compat here as
>>> well?
>>>
>>> I'm trying to understand if we actually didn't follow our own rules, or
>>> if the expectations of the community are exceeding the rules we have for
>>> ourselves. I think we're in the latter right now.
>>>
>>> On 3/28/14, 9:41 AM, Sean Busbey wrote:
>>>
>>>> According to the definition of the public API in version 1.5.0,
>>>> RangeInputSplit is a part of the public API.
>>>>
>>>>
>>>> On Fri, Mar 28, 2014 at 11:26 AM, Josh Elser <jo...@gmail.com>
>>>> wrote:
>>>>
>>>> Devil's advocate: RangeInputSplit isn't part of the public API
>>>>> either, so
>>>>> it comes with the same risks that TabletLocator would.
>>>>>
>>>>> It sounds more like the definition of "public api" should be expanded to
>>>>> prevent this in future cases. I need to look at what exactly broke
>>>>> for Don.
>>>>>
>>>>>
>>>>> On 3/28/14, 9:12 AM, Sean Busbey wrote:
>>>>>
>>>>> Don,
>>>>>>
>>>>>> If you can file a jira with some example code that covers what parts of
>>>>>> the
>>>>>> 1.5.0 API you hit, I can see if I can a patch to get you working.
>>>>>>
>>>>>> That would give you a patch you could apply on top of 1.5.1 now and
>>>>>> when
>>>>>> 1.5.2 comes out it would correctly support the API.
>>>>>>
>>>>>> -Sean
>>>>>>
>>>>>> On Fri, Mar 28, 2014 at 8: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 <jo...@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 <af...@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" <ct...@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 <af...@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
>>>>>>>>>>>>>> <ke...@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=3478f71ae888f8d73aaa93837319a6
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> dbb4ba0c8a
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> 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
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>
>>>>
Re: [VOTE] Apache Accumulo 1.5.1-RC3
Posted by Sean Busbey <bu...@cloudera.com>.
The README is already clear that everything under those packages is
included, with the exception of the impl pacakge.
In my reading, that means all Classes and Interfaces in any package under
the client package, and everything in those classes that is at either
public and protected access.
I guess this should be included in our pending discussion about
compatibility across versions?
On Fri, Mar 28, 2014 at 12:02 PM, Josh Elser <jo...@gmail.com> wrote:
> Also, reading back through this chain, it was state as unclear as to
> whether or not an inner class of a class in the public API is also, itself,
> in the public API.
>
> This should also be clarified in our definition of public API in the
> README. Obviously, Don and Sean both agree that it should be. The
> discussion of those on the vote didn't. Doesn't really matter to me either
> way.
>
>
> On 3/28/14, 9:50 AM, Josh Elser wrote:
>
>> Ah, I missed the recursiveness of the o.a.a.c.c.
>>
>> But, like I mentioned in the other message, I don't think binary compat
>> was achieved, but the package name, constructors, and methods existing
>> in 1.5.0 were maintained AFAIK. Are we asserting binary compat here as
>> well?
>>
>> I'm trying to understand if we actually didn't follow our own rules, or
>> if the expectations of the community are exceeding the rules we have for
>> ourselves. I think we're in the latter right now.
>>
>> On 3/28/14, 9:41 AM, Sean Busbey wrote:
>>
>>> According to the definition of the public API in version 1.5.0,
>>> RangeInputSplit is a part of the public API.
>>>
>>>
>>> On Fri, Mar 28, 2014 at 11:26 AM, Josh Elser <jo...@gmail.com>
>>> wrote:
>>>
>>> Devil's advocate: RangeInputSplit isn't part of the public API
>>>> either, so
>>>> it comes with the same risks that TabletLocator would.
>>>>
>>>> It sounds more like the definition of "public api" should be expanded to
>>>> prevent this in future cases. I need to look at what exactly broke
>>>> for Don.
>>>>
>>>>
>>>> On 3/28/14, 9:12 AM, Sean Busbey wrote:
>>>>
>>>> Don,
>>>>>
>>>>> If you can file a jira with some example code that covers what parts of
>>>>> the
>>>>> 1.5.0 API you hit, I can see if I can a patch to get you working.
>>>>>
>>>>> That would give you a patch you could apply on top of 1.5.1 now and
>>>>> when
>>>>> 1.5.2 comes out it would correctly support the API.
>>>>>
>>>>> -Sean
>>>>>
>>>>> On Fri, Mar 28, 2014 at 8: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 <jo...@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 <af...@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" <ct...@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 <af...@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
>>>>>>>>>>>>> <ke...@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=3478f71ae888f8d73aaa93837319a6
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> dbb4ba0c8a
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> 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
>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>
Re: [VOTE] Apache Accumulo 1.5.1-RC3
Posted by Josh Elser <jo...@gmail.com>.
Also, reading back through this chain, it was state as unclear as to
whether or not an inner class of a class in the public API is also,
itself, in the public API.
This should also be clarified in our definition of public API in the
README. Obviously, Don and Sean both agree that it should be. The
discussion of those on the vote didn't. Doesn't really matter to me
either way.
On 3/28/14, 9:50 AM, Josh Elser wrote:
> Ah, I missed the recursiveness of the o.a.a.c.c.
>
> But, like I mentioned in the other message, I don't think binary compat
> was achieved, but the package name, constructors, and methods existing
> in 1.5.0 were maintained AFAIK. Are we asserting binary compat here as
> well?
>
> I'm trying to understand if we actually didn't follow our own rules, or
> if the expectations of the community are exceeding the rules we have for
> ourselves. I think we're in the latter right now.
>
> On 3/28/14, 9:41 AM, Sean Busbey wrote:
>> According to the definition of the public API in version 1.5.0,
>> RangeInputSplit is a part of the public API.
>>
>>
>> On Fri, Mar 28, 2014 at 11:26 AM, Josh Elser <jo...@gmail.com>
>> wrote:
>>
>>> Devil's advocate: RangeInputSplit isn't part of the public API
>>> either, so
>>> it comes with the same risks that TabletLocator would.
>>>
>>> It sounds more like the definition of "public api" should be expanded to
>>> prevent this in future cases. I need to look at what exactly broke
>>> for Don.
>>>
>>>
>>> On 3/28/14, 9:12 AM, Sean Busbey wrote:
>>>
>>>> Don,
>>>>
>>>> If you can file a jira with some example code that covers what parts of
>>>> the
>>>> 1.5.0 API you hit, I can see if I can a patch to get you working.
>>>>
>>>> That would give you a patch you could apply on top of 1.5.1 now and
>>>> when
>>>> 1.5.2 comes out it would correctly support the API.
>>>>
>>>> -Sean
>>>>
>>>> On Fri, Mar 28, 2014 at 8: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 <jo...@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 <af...@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" <ct...@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 <jo...@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 <af...@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
>>>>>>>>>>>> <ke...@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=3478f71ae888f8d73aaa93837319a6
>>>>>>>>>>>>>> dbb4ba0c8a
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> 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
>>>>>
>>>>>
>>>>
>>
Re: [VOTE] Apache Accumulo 1.5.1-RC3
Posted by Josh Elser <jo...@gmail.com>.
Ah, I missed the recursiveness of the o.a.a.c.c.
But, like I mentioned in the other message, I don't think binary compat
was achieved, but the package name, constructors, and methods existing
in 1.5.0 were maintained AFAIK. Are we asserting binary compat here as well?
I'm trying to understand if we actually didn't follow our own rules, or
if the expectations of the community are exceeding the rules we have for
ourselves. I think we're in the latter right now.
On 3/28/14, 9:41 AM, Sean Busbey wrote:
> According to the definition of the public API in version 1.5.0,
> RangeInputSplit is a part of the public API.
>
>
> On Fri, Mar 28, 2014 at 11:26 AM, Josh Elser <jo...@gmail.com> wrote:
>
>> Devil's advocate: RangeInputSplit isn't part of the public API either, so
>> it comes with the same risks that TabletLocator would.
>>
>> It sounds more like the definition of "public api" should be expanded to
>> prevent this in future cases. I need to look at what exactly broke for Don.
>>
>>
>> On 3/28/14, 9:12 AM, Sean Busbey wrote:
>>
>>> Don,
>>>
>>> If you can file a jira with some example code that covers what parts of
>>> the
>>> 1.5.0 API you hit, I can see if I can a patch to get you working.
>>>
>>> That would give you a patch you could apply on top of 1.5.1 now and when
>>> 1.5.2 comes out it would correctly support the API.
>>>
>>> -Sean
>>>
>>> On Fri, Mar 28, 2014 at 8: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 <jo...@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 <af...@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" <ct...@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 <jo...@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 <af...@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 <ke...@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=3478f71ae888f8d73aaa93837319a6
>>>>>>>>>>>>> dbb4ba0c8a
>>>>>>>>>>>>>
>>>>>>>>>>>>> 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
>>>>
>>>>
>>>
>
Re: [VOTE] Apache Accumulo 1.5.1-RC3
Posted by Sean Busbey <bu...@cloudera.com>.
According to the definition of the public API in version 1.5.0,
RangeInputSplit is a part of the public API.
On Fri, Mar 28, 2014 at 11:26 AM, Josh Elser <jo...@gmail.com> wrote:
> Devil's advocate: RangeInputSplit isn't part of the public API either, so
> it comes with the same risks that TabletLocator would.
>
> It sounds more like the definition of "public api" should be expanded to
> prevent this in future cases. I need to look at what exactly broke for Don.
>
>
> On 3/28/14, 9:12 AM, Sean Busbey wrote:
>
>> Don,
>>
>> If you can file a jira with some example code that covers what parts of
>> the
>> 1.5.0 API you hit, I can see if I can a patch to get you working.
>>
>> That would give you a patch you could apply on top of 1.5.1 now and when
>> 1.5.2 comes out it would correctly support the API.
>>
>> -Sean
>>
>> On Fri, Mar 28, 2014 at 8: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 <jo...@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 <af...@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" <ct...@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 <jo...@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 <af...@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 <ke...@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=3478f71ae888f8d73aaa93837319a6
>>>>>>>>>>>> dbb4ba0c8a
>>>>>>>>>>>>
>>>>>>>>>>>> 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
>>>
>>>
>>
Re: [VOTE] Apache Accumulo 1.5.1-RC3
Posted by Josh Elser <jo...@gmail.com>.
Devil's advocate: RangeInputSplit isn't part of the public API either,
so it comes with the same risks that TabletLocator would.
It sounds more like the definition of "public api" should be expanded to
prevent this in future cases. I need to look at what exactly broke for Don.
On 3/28/14, 9:12 AM, Sean Busbey wrote:
> Don,
>
> If you can file a jira with some example code that covers what parts of the
> 1.5.0 API you hit, I can see if I can a patch to get you working.
>
> That would give you a patch you could apply on top of 1.5.1 now and when
> 1.5.2 comes out it would correctly support the API.
>
> -Sean
>
> On Fri, Mar 28, 2014 at 8:49 AM, Donald Miner <dm...@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 <jo...@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 <af...@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" <ct...@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 <jo...@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 <af...@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 <ke...@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
>>
>
Re: [VOTE] Apache Accumulo 1.5.1-RC3
Posted by Sean Busbey <bu...@cloudera.com>.
Don,
If you can file a jira with some example code that covers what parts of the
1.5.0 API you hit, I can see if I can a patch to get you working.
That would give you a patch you could apply on top of 1.5.1 now and when
1.5.2 comes out it would correctly support the API.
-Sean
On Fri, Mar 28, 2014 at 8:49 AM, Donald Miner <dm...@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 <jo...@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 <af...@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" <ct...@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 <jo...@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 <af...@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 <ke...@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
>
Re: [VOTE] Apache Accumulo 1.5.1-RC3
Posted by Donald Miner <dm...@clearedgeit.com>.
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 <jo...@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 <af...@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" <ct...@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 <jo...@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 <af...@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 <ke...@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 <jo...@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
Re: [VOTE] Apache Accumulo 1.5.1-RC3
Posted by Josh Elser <jo...@gmail.com>.
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 <af...@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" <ct...@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 <jo...@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 <af...@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 <ke...@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 <jo...@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
>>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>>
>
>
>
Re: [VOTE] Apache Accumulo 1.5.1-RC3
Posted by Josh Elser <jo...@gmail.com>.
Derp. I was looking right at that too and forgot that the parent class
would show up in the full name.
I'll make a ticket for that a while. That's easy enough to fix.
On 3/28/14, 9:46 AM, Sean Busbey wrote:
> the class name changed
>
> 1.5.0
>
> org.apache.accumulo.core.client.mapreduce.InputFormatBase.RangeInputSplit
>
> 1.5.1
>
> org.apache.accumulo.core.client.mapreduce.RangeInputSplit
>
> That breaks both source and binary compatibility. In this specific case,
> making things comaptible again isn't hard, but I want to make sure there
> aren't other changes that he needs.
>
>
> On Fri, Mar 28, 2014 at 11:41 AM, Josh Elser <jo...@gmail.com> wrote:
>
>> Don,
>>
>> What *exactly* happened in your application?
>>
>> Changes that were made added more information inside of RangeInputSplit,
>> as well as the class was moved to its own java file instead of being
>> embedded inside of InputFormatBase. The package did not change -- I imagine
>> you may have needed to recompile your application first, but... was there
>> more than that?
>>
>>
>> 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 <af...@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" <ct...@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 <jo...@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 <af...@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 <ke...@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 <jo...@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
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>>>
>>>
>
Re: [VOTE] Apache Accumulo 1.5.1-RC3
Posted by Sean Busbey <bu...@cloudera.com>.
the class name changed
1.5.0
org.apache.accumulo.core.client.mapreduce.InputFormatBase.RangeInputSplit
1.5.1
org.apache.accumulo.core.client.mapreduce.RangeInputSplit
That breaks both source and binary compatibility. In this specific case,
making things comaptible again isn't hard, but I want to make sure there
aren't other changes that he needs.
On Fri, Mar 28, 2014 at 11:41 AM, Josh Elser <jo...@gmail.com> wrote:
> Don,
>
> What *exactly* happened in your application?
>
> Changes that were made added more information inside of RangeInputSplit,
> as well as the class was moved to its own java file instead of being
> embedded inside of InputFormatBase. The package did not change -- I imagine
> you may have needed to recompile your application first, but... was there
> more than that?
>
>
> 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 <af...@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" <ct...@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 <jo...@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 <af...@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 <ke...@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 <jo...@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
>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>>
>>
>>
Re: [VOTE] Apache Accumulo 1.5.1-RC3
Posted by Josh Elser <jo...@gmail.com>.
Don,
What *exactly* happened in your application?
Changes that were made added more information inside of RangeInputSplit,
as well as the class was moved to its own java file instead of being
embedded inside of InputFormatBase. The package did not change -- I
imagine you may have needed to recompile your application first, but...
was there more than that?
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 <af...@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" <ct...@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 <jo...@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 <af...@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 <ke...@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 <jo...@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
>>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>>
>
>
>
Re: [VOTE] Apache Accumulo 1.5.1-RC3
Posted by Donald Miner <dm...@clearedgeit.com>.
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 <af...@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" <ct...@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 <jo...@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 <af...@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 <ke...@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 <jo...@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
Re: [VOTE] Apache Accumulo 1.5.1-RC3
Posted by Adam Fuchs <af...@apache.org>.
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" <ct...@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 <jo...@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 <af...@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 <ke...@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 <jo...@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
> >>>>>
> >>>>
> >>>
> >>
> >
>
Re: [VOTE] Apache Accumulo 1.5.1-RC3
Posted by Christopher <ct...@apache.org>.
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 <jo...@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 <af...@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 <ke...@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 <jo...@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
>>>>>
>>>>
>>>
>>
>
Re: [VOTE] Apache Accumulo 1.5.1-RC3
Posted by Josh Elser <jo...@gmail.com>.
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 <af...@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 <ke...@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 <jo...@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
>>>>
>>>
>>
>
Re: [VOTE] Apache Accumulo 1.5.1-RC3
Posted by John Vines <vi...@apache.org>.
Will it? Clients don't interact with that code at all directly.
On Tue, Feb 25, 2014 at 5:57 PM, Adam Fuchs <af...@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 <ke...@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 <jo...@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
> > >
> >
>
Re: [VOTE] Apache Accumulo 1.5.1-RC3
Posted by Adam Fuchs <af...@apache.org>.
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 <ke...@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 <jo...@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
> >
>
Re: [VOTE] Apache Accumulo 1.5.1-RC3
Posted by Keith Turner <ke...@deenlo.com>.
On Thu, Feb 27, 2014 at 6:16 PM, Christopher <ct...@apache.org> wrote:
> +1
>
> I've run my verifier script [1] several times, on CentOS 6.5, Fedora
> 19, Fedora 20 (at least half a dozen now, and at least twice on each),
> to verify the following:
>
> All signatures and hashes are good, including the RPM sigs.
> Jars have sources/javadocs, are sealed, and match the binary tarball
> contents.
> Source tarball matches the git tag (3478f71a), and builds with and
> without tests with the configured hadoop.profile=1 and
> hadoop.profile=2.
>
> Some of the integration tests time out occasionally on a CentOS 6.5
> build in a VM, but I'm not too concerned about the time-sensitivity in
> those tests.
>
> Did the following tests on CentOS 6.5, Hadoop 1.2.1, ZK 3.4.5,
> (3GB-standalone-native), OpenJDK 1.6
> (java-1.6.0-openjdk-1.6.0.0-3.1.13.1.el6_5.x86_64):
> Started/stopped a single-node cluster, created/deleted tables, ran
> test/verify ingest (test/system/test1)
> Write performance (5 threads * ~40k mut/sec = ~200k mut/sec)
> Read performance (5 threads * ~109k rec/sec = ~545k rec/sec)
>
I am seeing slow write speeds when running test/system/test1/ingest_test.sh
w/ a single node Hadoop 2.2.0. I have confirmed this is ACCUMULO-1905,
when I increase tserver.mutation.queue.max to 4M, write rates are around
200k mut/sec. When tserver.mutation.queue.max is at the default value, it
writes at around 1/5th the speed. I added some notes to 1905.
>
> I did run into a strange bug where I couldn't start the master... the
> java process would just die unexpectedly while setting up log4j,
> without logging anything to stdout or stderr. The problem was fixed
> after a reboot, so I wasn't able to reproduce or debug it, and I don't
> think it's an Accumulo bug (probably kernel or openjdk bug).
>
> [1]: https://github.com/ctubbsii/rc-verify
>
> --
> Christopher L Tubbs II
> http://gravatar.com/ctubbsii
>
>
> On Tue, Feb 25, 2014 at 5:17 PM, Keith Turner <ke...@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 <jo...@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
> >>
>
Re: [VOTE] Apache Accumulo 1.5.1-RC3
Posted by Christopher <ct...@apache.org>.
+1
I've run my verifier script [1] several times, on CentOS 6.5, Fedora
19, Fedora 20 (at least half a dozen now, and at least twice on each),
to verify the following:
All signatures and hashes are good, including the RPM sigs.
Jars have sources/javadocs, are sealed, and match the binary tarball contents.
Source tarball matches the git tag (3478f71a), and builds with and
without tests with the configured hadoop.profile=1 and
hadoop.profile=2.
Some of the integration tests time out occasionally on a CentOS 6.5
build in a VM, but I'm not too concerned about the time-sensitivity in
those tests.
Did the following tests on CentOS 6.5, Hadoop 1.2.1, ZK 3.4.5,
(3GB-standalone-native), OpenJDK 1.6
(java-1.6.0-openjdk-1.6.0.0-3.1.13.1.el6_5.x86_64):
Started/stopped a single-node cluster, created/deleted tables, ran
test/verify ingest (test/system/test1)
Write performance (5 threads * ~40k mut/sec = ~200k mut/sec)
Read performance (5 threads * ~109k rec/sec = ~545k rec/sec)
I did run into a strange bug where I couldn't start the master... the
java process would just die unexpectedly while setting up log4j,
without logging anything to stdout or stderr. The problem was fixed
after a reboot, so I wasn't able to reproduce or debug it, and I don't
think it's an Accumulo bug (probably kernel or openjdk bug).
[1]: https://github.com/ctubbsii/rc-verify
--
Christopher L Tubbs II
http://gravatar.com/ctubbsii
On Tue, Feb 25, 2014 at 5:17 PM, Keith Turner <ke...@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 <jo...@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
>>
Re: [VOTE] Apache Accumulo 1.5.1-RC3
Posted by Keith Turner <ke...@deenlo.com>.
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 <jo...@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
>
Re: [VOTE] Apache Accumulo 1.5.1-RC3
Posted by Bill Havanki <bh...@clouderagovt.com>.
+1
Ran unit tests, functional tests, greater than 24-hour randomwalk with full
agitation. Found ACCUMULO-2422 but I don't consider it a blocker.
Cluster: Hadoop 2.0.0 on CDH4.5 with HA+QJM, ZK 3.4.5 on CDH, 7 nodes (2
masters / 5 tservers / 3 ZK)
On Thu, Feb 27, 2014 at 5:32 PM, John Vines <jv...@gmail.com> wrote:
> +1
>
> I grabbed the tag, built it, and ran ingest and queries against it
> overnight.
>
>
> On Thu, Feb 27, 2014 at 4:51 PM, Eric Newton <er...@gmail.com>
> wrote:
>
> > +1
> >
> > I downloaded the bin tarball, unpacked it, and ran the integration tests.
> >
> >
> >
> > On Mon, Feb 24, 2014 at 8:01 PM, Josh Elser <jo...@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
> > >
> >
>
>
>
> --
> Cheers
> ~John
>
--
| - - -
| Bill Havanki
| Solutions Architect, Cloudera Government Solutions
| - - -
Re: [VOTE] Apache Accumulo 1.5.1-RC3
Posted by John Vines <jv...@gmail.com>.
+1
I grabbed the tag, built it, and ran ingest and queries against it
overnight.
On Thu, Feb 27, 2014 at 4:51 PM, Eric Newton <er...@gmail.com> wrote:
> +1
>
> I downloaded the bin tarball, unpacked it, and ran the integration tests.
>
>
>
> On Mon, Feb 24, 2014 at 8:01 PM, Josh Elser <jo...@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
> >
>
--
Cheers
~John
Re: [VOTE] Apache Accumulo 1.5.1-RC3
Posted by Eric Newton <er...@gmail.com>.
+1
I downloaded the bin tarball, unpacked it, and ran the integration tests.
On Mon, Feb 24, 2014 at 8:01 PM, Josh Elser <jo...@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
>
Re: [VOTE] Apache Accumulo 1.5.1-RC3
Posted by Keith Turner <ke...@deenlo.com>.
On Thu, Feb 27, 2014 at 8:29 PM, Josh Elser <jo...@gmail.com> wrote:
> I was actually planning to write up some release notes after the fact
> (probably throw them up by the download link).
>
Ok, I thnik thats the way to go. I was thinking back on why I did not
change the default in 1.5 when I changed it for 1.6. I think I was
concerned about destabilizing a Hadoop 1+Accumulo 1.5.0 after upgrade. I
think if we changed the default we would still need release notes warning
people about the possibility of additional mem usage after upgrade.
>
> I am on my phone, but I thought the mutation queue size affected 1.5 and
> greater (read as hdfs wal), not just hadoop 2.2.0. My memory could also
> just be failing me.
> On Feb 27, 2014 7:38 PM, "Keith Turner" <ke...@deenlo.com> wrote:
>
> > I have not voted because of the Hadoop 2.2.0 performance issue. I spoke
> > w/ Christopher about this he suggested that if we had release notes this
> > would not be a problem. So it seems like our options for 1.5.1-RC3 and
> > 1905 are the following.
> >
> > 1. Ingore it
> > 2. Create release notes that prominently mentions the Hadoop 2.2.0
> > performance issue and workarounds
> > 3. Create a 1.5.1-RC4 w/ different a different default for
> > tserver.mutation.queue.max
> >
> > I don't mind creating the release notes. I am still puzzling over what
> the
> > best option is for the long term.
> >
> > On Mon, Feb 24, 2014 at 8:01 PM, Josh Elser <jo...@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
> > >
> >
>
Re: [VOTE] Apache Accumulo 1.5.1-RC3
Posted by Josh Elser <jo...@gmail.com>.
(Semi) answering my own question:
Looks like hsync (HDFS-744) has a fix version of 2.0.2. There was some talk
about getting that in the 1.0 line but I don't see a resolution for that.
I'm also not sure how sync was done (if it all reliably?) in the hadoop 1
line.
On Feb 27, 2014 8:28 PM, josh.elser@gmail.com wrote:
> I was actually planning to write up some release notes after the fact
> (probably throw them up by the download link).
>
> I am on my phone, but I thought the mutation queue size affected 1.5 and
> greater (read as hdfs wal), not just hadoop 2.2.0. My memory could also
> just be failing me.
> On Feb 27, 2014 7:38 PM, "Keith Turner" <ke...@deenlo.com> wrote:
>
>> I have not voted because of the Hadoop 2.2.0 performance issue. I spoke
>> w/ Christopher about this he suggested that if we had release notes this
>> would not be a problem. So it seems like our options for 1.5.1-RC3 and
>> 1905 are the following.
>>
>> 1. Ingore it
>> 2. Create release notes that prominently mentions the Hadoop 2.2.0
>> performance issue and workarounds
>> 3. Create a 1.5.1-RC4 w/ different a different default for
>> tserver.mutation.queue.max
>>
>> I don't mind creating the release notes. I am still puzzling over what
>> the
>> best option is for the long term.
>>
>> On Mon, Feb 24, 2014 at 8:01 PM, Josh Elser <jo...@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
>> >
>>
>
Re: [VOTE] Apache Accumulo 1.5.1-RC3
Posted by Josh Elser <jo...@gmail.com>.
I was actually planning to write up some release notes after the fact
(probably throw them up by the download link).
I am on my phone, but I thought the mutation queue size affected 1.5 and
greater (read as hdfs wal), not just hadoop 2.2.0. My memory could also
just be failing me.
On Feb 27, 2014 7:38 PM, "Keith Turner" <ke...@deenlo.com> wrote:
> I have not voted because of the Hadoop 2.2.0 performance issue. I spoke
> w/ Christopher about this he suggested that if we had release notes this
> would not be a problem. So it seems like our options for 1.5.1-RC3 and
> 1905 are the following.
>
> 1. Ingore it
> 2. Create release notes that prominently mentions the Hadoop 2.2.0
> performance issue and workarounds
> 3. Create a 1.5.1-RC4 w/ different a different default for
> tserver.mutation.queue.max
>
> I don't mind creating the release notes. I am still puzzling over what the
> best option is for the long term.
>
> On Mon, Feb 24, 2014 at 8:01 PM, Josh Elser <jo...@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
> >
>
Re: [VOTE] Apache Accumulo 1.5.1-RC3
Posted by Keith Turner <ke...@deenlo.com>.
I have not voted because of the Hadoop 2.2.0 performance issue. I spoke
w/ Christopher about this he suggested that if we had release notes this
would not be a problem. So it seems like our options for 1.5.1-RC3 and
1905 are the following.
1. Ingore it
2. Create release notes that prominently mentions the Hadoop 2.2.0
performance issue and workarounds
3. Create a 1.5.1-RC4 w/ different a different default for
tserver.mutation.queue.max
I don't mind creating the release notes. I am still puzzling over what the
best option is for the long term.
On Mon, Feb 24, 2014 at 8:01 PM, Josh Elser <jo...@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
>