[accumulo] update binding to 1.7.2

[madrob]

No description provided.

[busbey]

are folks likely to want to compare 1.6 to 1.7?

[busbey]

was this on purpose?

[madrob]

Yes. I left the root logger at INFO so there is no user-facing change, but this makes future debugging easier.

[busbey]

ah. ✅

[busbey]

related to the "compare 1.6 to 1.7", can this updated client talk to a 1.6 cluster?

[busbey]

the only concern I can see would be that we still haven't broken out versioned accumulo clients (as we do for e.g. hbase098 and hbase10). So when this change goes in, folks might not be able to use a single YCSB deployment to compare and Accumulo 1.6 deployment to Accumulo 1.7. If this client can talk to both 1.6 and 1.7 clusters, I'm less concerned (though I guess that means folks would still have a hard time comparing changes in the client-side code).

[busbey]

one of the failures was the known flakey for Cassandra managing to start in time. the other one looks like maybe the Accumulo 1.7 minicluster might have similar issues? Is there a timeout we can make more forgiving?

[busbey]

@madrob I've tried restarting the travis-ci run a few times and it's consistently failing to start in time in openjdk7.

Any opinions on the ease of comparing 1.6 and 1.7 @joshelser or @ctubbsii

[joshelser]

Any opinions on the ease of comparing 1.6 and 1.7

I would guess that a 1.6 client can still talk to a 1.7 cluster (via public API), but not something I've tested directly either. I should really try to get more involved here too. Let me see if I can test it out locally.

[busbey]

I believe this would change the client to be 1.7. Any idea if a 1.7 client can talk to a 1.6 cluster?

Even if they can, when comparing things would you want to see differences caused by client version changes between 1.6 and 1.7?

[joshelser]

I believe this would change the client to be 1.7. Any idea if a 1.7 client can talk to a 1.6 cluster?

A similar (or slightly less) degree of confidence than 1.6->1.7 :)

Even if they can, when comparing things would you want to see differences caused by client version changes between 1.6 and 1.7?

Comparing things==perf? I think it would be nice to know if it's implying that a version X client can talk to a version X+1 cluster.

[risdenk]

Looks like this actually failed. Is this possible due to the version upgrade?

Running com.yahoo.ycsb.db.accumulo.AccumuloTest
2016/07/05 03:03:38 DEBUG com.yahoo.ycsb.db.accumulo.AccumuloTest  - starting minicluster
*** buffer overflow detected ***: /usr/lib/jvm/java-7-openjdk-amd64/jre/bin/java terminated
...

[busbey]

I think maybe the 1.7 minicluster takes a little longer to get going, which gets us this failure. AFAICT it passes locally.

Given that Accumulo 1.6 is reaching the end of its life upstream, I think it's worth breaking this into two verisoned modules (or three, since 1.8 is out now).

[joshelser]

I think it's worth breaking this into two verisoned modules (or three, since 1.8 is out now).

For running these tests, having the correct versions of the Accumulo client on the classpath? From the Accumulo API, we shouldn't need to do this.

[ctubbsii]

The buffer overflow is probably the OpenJDK bug with the long hostnames Travis provides. See travis-ci/travis-ci#5227.

The workaround is to set a custom hostname and add that hostname to /etc/hosts ... or avoid the buggy openjdk in Travis entirely.

[busbey]

I think it's worth breaking this into two verisoned modules (or three, since 1.8 is out now).

For running these tests, having the correct versions of the Accumulo client on the classpath? From the Accumulo API, we shouldn't need to do this.

yeah, for allowing folks to test the impact of changes in the Accumulo client. nothing to do with API use at first cut. We might later want to incorporate some of the newer client side APIs (e.g. KerberosToken).

[busbey]

The workaround is to set a custom hostname and add that hostname to /etc/hosts ... or avoid the buggy openjdk in Travis entirely.

That work around would require us to get off of the container based infra (since it requires sudo). Did openjdk never provide a fixed version for openjdk7? I guess we could start a thread about switching to openjdk8 instead of openjdk7, but I'd want that broken out from an Accumulo PR since it would mean relying on just the oracle jdk7 for jdk7 checks.

[risdenk]

@busbey the "new" workaround may not require sudo.

travis-ci/travis-ci#5227 (comment)

addons:
  hosts:
    - myshorthost
  hostname: myshorthost

[busbey]

the docs for hostname that @ctubbsii pointed to state that it requires sudo images.

[risdenk]

ah ok :(

[ctubbsii]

Yeah, it requires sudo, unfortunately. Not sure when/if it matters that it can't use the container infrastructure.

It looks like it was fixed in Java 8. Since 7 is basically EOL, and it really only affects Docker users in most cases, I suspect it won't be patched in 7. And, even if it were, there's no guarantee when/if Travis would update.

[risdenk]

@joshelser or @madrob - Any plans to update this?

[risdenk]

Needs to at least be rebased

[joshelser]

That work around would require us to get off of the container based infra (since it requires sudo). Did openjdk never provide a fixed version for openjdk7

Do you recall if this happened, @risdenk? Being lazy :)

[risdenk]

@joshelser not sure. I never checked.

[busbey]

following up: we did not get off of the container based infra (it's the travis preferred option for projects). Also we now rely entirely on openjdk7 since oraclejdk7 went away. I don't know if there's a fix for openjdk7