accumulo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Donald Miner <dmi...@clearedgeit.com>
Subject Re: [VOTE] Apache Accumulo 1.5.1-RC3
Date Fri, 28 Mar 2014 13:49:07 GMT
I'm starting to dig around for a workaround and figured someone might be
able to help me right away.

In digging deeper, we were using RangeInputSplit because it gave us the
splits AND the locations. We use the locations for some data locality
placing in our distributed application. listSplits only gives us splits.

Is there an easy way to get both of these pieces of information together?


On Thu, Mar 27, 2014 at 3:28 PM, Josh Elser <josh.elser@gmail.com> wrote:

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


-- 

Donald Miner
Chief Technology Officer
ClearEdge IT Solutions, LLC
Cell: 443 799 7807
www.clearedgeit.com

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