Since there was a discussion thread on this, I wanted to bring this up on the list instead of just leaving a comment on the issue.
I just bisect'ed a failing MetaSplitIT and found that the changes introduced by bumping to 0.9.1 were what supposedly introduced them. The thing that worries me is that putting this in 1.6.1 came with a "it's compatible" guarantee, when, to be perfectly honest, it's obviously not at the level of compatibility that we want it to be for a bug-fix release (it broke a test).
Now, I haven't traced it back far enough to see what has exactly changed with the exceptions (causing us to poll indefinitely instead of fail back to the client), but that makes me worry that assumptions we have in the implementation of our API, WRT exception handling, are suddenly invalid.
I'll try to poke around at this some more to figure it out exactly.
For completeness here, and to wrap up this thread, the issue was identified as caused by THRIFT-1805, which regressed (a second time) an issue which suppressed TApplicationExceptions and simply caused the connection to be closed, resulting in what looked like a network issue (TTransportException) in the client.
ACCUMULO-2950 was opened to deal with this, and the patch is being tested, and is expected to restore the original behavior in 0.9.0. It does fix the issue identified in ACCUMULO-2935, but I made it a separate issue, so it was clearly documenting the underlying problem, separately from the symptom.
Further, I reviewed the entire changeset from 0.9.0 to 0.9.1 in libthrift.jar and I didn't see any other changes that should cause any trouble for us. Christopher L Tubbs II http://gravatar.com/ctubbsii On Sun, Jun 22, 2014 at 5:41 PM, Josh Elser <[EMAIL PROTECTED]> wrote:
Apache Lucene, Apache Solr and all other Apache Software Foundation projects and their respective logos are trademarks of the Apache Software Foundation.
Elasticsearch, Kibana, Logstash, and Beats are trademarks of Elasticsearch BV, registered in the U.S. and in other countries. This site and Sematext Group is in no way affiliated with Elasticsearch BV.
Service operated by Sematext