nea/vertx-mod-cassandra-persistor

Running in multi-threaded mode can cause InvalidTypeException

Closed this issue · 2 comments

When the default value of "multi-threaded": true is left as-is in the included mod.json file, the below code leads to an InvalidTypeException from the datastax driver. The code example is in Groovy, though I would guess it could be reproduced in Java as well:

vertx.eventBus.send("cassandra", [
  "action"   : "prepared",
  "statement": "INSERT INTO keyspace.table1(string1, string2, timestamp1) VALUES(?, ?, ?)",
  "values"   : [
    ["foo", "bar", "2014-09-26 03:04:40-0500"]
  ]
])
vertx.eventBus.send("cassandra", [
  "action"   : "prepared",
  "statement": "INSERT INTO keyspace.table2(string1, string2, timestamp1) VALUES(?, ?, ?)",
  "values"   : [
    ["foo", "bar", "2014-09-26 03:04:40-0500"]
  ]
])

Here is the stacktrace that sometimes occurs:

[Cassandra Persistor] Invalid type for value 2 of CQL type timestamp, expecting class java.util.Date but class java.lang.String provided
com.datastax.driver.core.exceptions.InvalidTypeException: Invalid type for value 2 of CQL type timestamp, expecting class java.util.Date but class java.lang.String provided
    at com.datastax.driver.core.BoundStatement.bind(BoundStatement.java:199)
    at com.insanitydesign.vertx.CassandraPersistor.prepared(CassandraPersistor.java:230)
    at com.insanitydesign.vertx.CassandraPersistor.handle(CassandraPersistor.java:188)
    at com.insanitydesign.vertx.CassandraPersistor.handle(CassandraPersistor.java:46)
    at org.vertx.java.core.eventbus.impl.DefaultEventBus$11.run(DefaultEventBus.java:951)
    at org.vertx.java.core.impl.DefaultContext$3.run(DefaultContext.java:175)
    at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
    at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
    at java.lang.Thread.run(Thread.java:722)

When I directly include this mod in my project's mods folder and remove the "multi-threaded": true line, I am then unable to reproduce the issue and everything works as expected.

Any ideas what may be going on here? I can create a pull request with the line omitted, but thought it'd be better to bring it to your attention first.

nea commented

Hi there

Oh damn. I actually wanted the module to be multi-threaded safe, but it seems I messed up there a bit. I have to check this out and will try to fix it as soon as possible. If I really cannot get around, I would have to make it non multi-threaded as fallback. Thanks for the checking already ^^

Thanks a lot

nea commented

Please check the newest version 0.4.1