Cassaforte calls not-existent method set_cql_version
Closed this issue · 7 comments
After creating the keyspace CascadingCassandra I run midje tests for cascading-cassandra, which uses cassaforte version "1.0.0-20120920.162529-8", and it attemps to call a method of org.apache.cassandra.thrift.Cassandra.Client that does not exist.
"Exception in thread "main" java.lang.RuntimeException: org.apache.thrift.TApplicationException: Invalid method name: 'set_cql_version'"
The call is made at https://github.com/clojurewerkz/cassaforte/blob/master/src/java/clojurewerkz/cassaforte/CassandraClient.java#L70
This could be a conflict of versions. Note that running with lein-pedantic shows a number conflicts causing potentially unexpected versions of libraries to be used.
Sorry for a long delay with an answer.
Just checked it all.
Are you running cascading-cassandra as a standalone library or do you have per change cassandra-thrift or cassandra-all libraries also used together with it?.. I just checked all versions, seems to be all right, nuked my maven repo and reassembled also fine.
Try now, should all be way better :)
I did find a couple of issues with lein-pedantic.
On the bright side, cassaforte is now 1.3 compatible
Thank you for helping to solve this problem. I am still having the same problem described above. Could it be that there is some undocumented requirement that I am missing?
I am running this in Ubuntu using Java 7 (same result running with Java 6). I have cleared out maven cache and cleaned out ./target, and I am using lein-midje version 2.0.1.
lein do clean, midje
Compiling 6 source files to /home/rlevy/prj/cascading-cassandra/target/classes
Note: /home/rlevy/prj/cascading-cassandra/src/main/java/com/clojurewerkz/cascading/cassandra/CassandraScheme.java uses or overrides a deprecated API.
Note: Recompile with -Xlint:deprecation for details.
Note: Some input files use unchecked or unsafe operations.
Note: Recompile with -Xlint:unchecked for details.
Listening for transport dt_socket at address: 60355
Exception in thread "main" java.lang.RuntimeException: org.apache.thrift.TApplicationException: Invalid method name: 'set_cql_version'
at clojure.lang.Util.runtimeException(Util.java:165)
at clojure.lang.Compiler.eval(Compiler.java:6476)
at clojure.lang.Compiler.load(Compiler.java:6902)
at clojure.lang.RT.loadResourceScript(RT.java:357)
at clojure.lang.RT.loadResourceScript(RT.java:348)
at clojure.lang.RT.load(RT.java:427)
at clojure.lang.RT.load(RT.java:398)
at clojure.core$load$fn__4610.invoke(core.clj:5386)
at clojure.core$load.doInvoke(core.clj:5385)
at clojure.lang.RestFn.invoke(RestFn.java:408)
at clojure.core$load_one.invoke(core.clj:5200)
at clojure.core$load_lib.doInvoke(core.clj:5237)
at clojure.lang.RestFn.applyTo(RestFn.java:142)
at clojure.core$apply.invoke(core.clj:602)
at clojure.core$load_libs.doInvoke(core.clj:5271)
at clojure.lang.RestFn.applyTo(RestFn.java:137)
at clojure.core$apply.invoke(core.clj:602)
at clojure.core$require.doInvoke(core.clj:5352)
at clojure.lang.RestFn.invoke(RestFn.java:408)
at user$eval25$fn__46.doInvoke(NO_SOURCE_FILE:1)
at clojure.lang.RestFn.applyTo(RestFn.java:137)
at clojure.core$apply.invoke(core.clj:600)
at user$eval25.invoke(NO_SOURCE_FILE:1)
at clojure.lang.Compiler.eval(Compiler.java:6465)
at clojure.lang.Compiler.eval(Compiler.java:6455)
at clojure.lang.Compiler.eval(Compiler.java:6431)
at clojure.core$eval.invoke(core.clj:2795)
at clojure.main$eval_opt.invoke(main.clj:296)
at clojure.main$initialize.invoke(main.clj:315)
at clojure.main$null_opt.invoke(main.clj:348)
at clojure.main$main.doInvoke(main.clj:426)
at clojure.lang.RestFn.invoke(RestFn.java:421)
at clojure.lang.Var.invoke(Var.java:405)
at clojure.lang.AFn.applyToHelper(AFn.java:163)
at clojure.lang.Var.applyTo(Var.java:518)
at clojure.main.main(main.java:37)
Caused by: org.apache.thrift.TApplicationException: Invalid method name: 'set_cql_version'
at org.apache.thrift.TApplicationException.read(TApplicationException.java:108)
at org.apache.thrift.TServiceClient.receiveBase(TServiceClient.java:71)
at org.apache.cassandra.thrift.Cassandra$Client.recv_set_cql_version(Cassandra.java:1500)
at org.apache.cassandra.thrift.Cassandra$Client.set_cql_version(Cassandra.java:1487)
at clojurewerkz.cassaforte.CassandraClient.(CassandraClient.java:70)
at clojurewerkz.cassaforte.client$connect_BANG_.invokePrim(client.clj:29)
at clojurewerkz.cassaforte.client$connect_BANG_.invoke(client.clj:31)
at com.clojurewerkz.cascading.cassandra.core_test$eval5364.invoke(core_test.clj:22)
at clojure.lang.Compiler.eval(Compiler.java:6465)
... 34 more
Subprocess failed
I find it hard to see how this could possibly work. Are you sure you are cleaning out old class files before running it in your dev environment? On the one hand it is using a deprecated API, but if I set back cassandra-all to a 1.0.x version there are errors indicating it is using the new API.
Honestly, I run it on CI, too: https://travis-ci.org/ifesdjeen/cascading-cassandra and it seems to pass just fine.
But there seems to be a deeper problem somewhere.
Note:. ../cascading-cassandra/src/main/java/com/clojurewerkz/cascading/cassandra/CassandraScheme.java uses or overrides a deprecated API.
That one is not our fault, frankly. Problem is that we're using deprecated API from Cassandra-Hadoop, because otherwise we would have had to re-implement everything from scratch ourselves completely. Old API uses JobConf and JobClient, new one has Job, splits are calculated differently. And well, Cascading does not support it just yet, at least 2.0 one, that works with Cascalog 0.10 iirc
OH MY......
I think I just got what is going on...
Which version of Cassandra are you using?...
BTW, I'm running lein do clean, test. I only use Midje internally, other than that I use old clojure.test api.
Just for sakes of an experiment, try turning off your cassandra and running lein do clean, test. You should be able to see connection error on port blah blah.
Interesting... I did think of that but I didn't think it would cause this type of error. I was wrong (most likely)! Turning off cassandra and running lein midje or test does produce the expected behavior of failing to connect (TTransportException). What version of Cassandra have you tested this with? I've been using 1.0.12 in my dev environment.
And come to think of it, I just set up this new workstation recently and I was a tad sloppy apparently as we are using 1.1.5 in production so I really should be testing locally with the same version. I think I used apt-get (in my haste) and got a really old version of course. EDIT: it was the version! The tests pass with newer versions of cassandra.
1.1.5 should be absolutely fine. We're still on 1.1.0, so should be all good.
We're using distribution from datastax, their apt repo is usually a good way to go)