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
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
[
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 mino
Will it? Clients don't interact with that code at all directly.
On Tue, Feb 25, 2014 at 5:57 PM, Adam Fuchs 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 (runtim
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 wrote:
Thanks f
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
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" wrote:
> I don't know that this inner class used for M/R should be considered
> public API...
+1
I downloaded the bin tarball, unpacked it, and ran the integration tests.
On Mon, Feb 24, 2014 at 8:01 PM, Josh Elser 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 bu
+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 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 wrote:
>
> > All,
> >
> >
+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 wro
+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
On Thu, Feb 27, 2014 at 6:16 PM, Christopher 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.
>
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
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
(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.el..
On Thu, Feb 27, 2014 at 8:29 PM, Josh Elser 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.
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 wrote:
> All,
>
> Please consider the fol
Just tried it. It worked fine.
-Eric
On Fri, Feb 28, 2014 at 10:20 AM, Keith Turner 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 el
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 a
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://gra
I went ahead and marked 1.5.1 as released in JIRA. Team effort!
On Fri, Feb 28, 2014 at 2:18 PM, Christopher 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
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
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 refer
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 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 wrote:
> Devil's advocate: RangeInputSplit isn't part of the public API either, so
> it comes with the same risks that TabletLocator would.
>
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 re
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.InputFormatBas
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.
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 wrote:
> You could use listSplits() and then tablet locator
>
>
> http://accumulo.apache.org/1.4/apidocs/org/apache/accumulo/core/client/impl
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, 2
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
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
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 wrote:
> The README is a
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 gues
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
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:1
You could use listSplits() and then tablet locator
http://accumulo.apache.org/1.4/apidocs/org/apache/accumulo/core/client/impl/TabletLocator.html
On Fri, Mar 28, 2014 at 9:49 AM, Donald Miner wrote:
> I'm starting to dig around for a workaround and figured someone might be
> able to help me rig
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
Yes. This is exactly what was discussed earlier in this thread.
On Mar 28, 2014 10:35 AM, "Christopher" 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.
>
> --
>
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 wrote:
> Yes. This is exactly what was discussed earlier in this thread.
> On Mar 28, 2014 10:35 AM, "Christopher" wrote:
>
> > That README was probabl
That was my interpretation as well.
On Fri, Mar 28, 2014 at 3:13 PM, Mike Drob 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 wrote:
>
> > Yes. This is exactly what was discussed ea
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
somethi
Filed as ACCUMULO-2590
https://issues.apache.org/jira/browse/ACCUMULO-2590
On Fri, Mar 28, 2014 at 2:56 PM, Josh Elser 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 pub
43 matches
Mail list logo
