JanusGraph 0.6.0 Binary Driver failing on serialization


We have fully integrated our backend with JS:0.6 as recommended, including DB connection using new driver: GraphBinaryMessageSerializerV1.

All seams o work as before, except:

GraphTraversal<Vertex, ? extends Property<Object>> p = g.V(12345).properties("myproperty");

if (p.hasNext()) {...}


12:02:47.609 [https-jsse-nio-] ERROR o.a.c.c.C.[.[.[.[dispatcherServlet] [175] - Servlet.service() for servlet [dispatcherServlet] in context with path [] threw exception [Request processing failed; nested exception is java.util.concurrent.CompletionException: org.apache.tinkerpop.gremlin.driver.exception.ResponseException: Error during serialization: java.lang.IllegalStateException] with root cause

org.apache.tinkerpop.gremlin.driver.exception.ResponseException: Error during serialization: java.lang.IllegalStateException

at org.apache.tinkerpop.gremlin.driver.Handler$GremlinResponseHandler.channelRead0(Handler.java:245)

at org.apache.tinkerpop.gremlin.driver.Handler$GremlinResponseHandler.channelRead0(Handler.java:200)

at io.shaded.netty.channel.SimpleChannelInboundHandler.channelRead(SimpleChannelInboundHandler.java:99)



Above was, and still is fine on p.hasNext() with previously used GryoMessageSerializerV3d0 driver. Workaround we have is to use:

GraphTraversal<Vertex, ? extends Property<Object>> p = g.V(12345).values("myproperty");


if (p.hasNext()) {...}  // now is ok


Why above is failing, is the question....

Regards, Chris 




Hi Chris,

Thanks for reporting.  I could confirm the exception you got by using the console and server files from the distribution. I got the right results, though,  when I changed the contents of conf/remote-graph-binary.yaml to:

hosts: [localhost]
port: 8182
serializer: { className: org.apache.tinkerpop.gremlin.driver.ser.GraphBinaryMessageSerializerV1, config: { ioRegistries: [org.janusgraph.graphdb.tinkerpop.JanusGraphIoRegistry], serializeResultToString: true }}

in this way, it matches the configs of gremlin-server in conf/gremlin-server/gremin-server.yaml

I will post a ticket for it.

Best wishes,      Marc



Thank you Marc,

I was able to reproduce your sample by console:  :remote connect tinkerpop.server conf/remote.yaml session  # it is GryoMessageSerializerV3d0 - no problem here, but must have serializeResultToString: true 

:remote connect tinkerpop.server conf/remote-graph-binary.yaml session

:> g.V().properties("some")    ==> Server error - Error during serialization: java.lang.IllegalStateException. 

:> g.V().properties("some").hasNext() => true, it is actually working in this context, where server testing the results, not the client after serialization.

It is fine when "remote-graph-binary.yaml" configuration is equipped with serializeResultToString: true. 


That hint should indicate that our server is different that the driver we use in java to remote access, but with more debugging I cannot say where is it... We run JanusGraph services through "bin/gremlin-server-websoc.sh", that suppose to run new Binary Driver with gremlin-server-websoc.yaml (+serializeResultToString: true). Then we getting remote access from Java by connection with 

    MessageSerializer<?> serializer = new GraphBinaryMessageSerializerV1(typeSerializerRegistry);

To be sure, we have true for serializeResultToString in the configuration, we even modified that on fly:

    final Map<String, Object> cfg = new HashMap<>();  cfg.put("serializeResultToString",true);     serializer.configure(cfg, null);

With serializeResultToString(true) we have the same exception IllegalStageException as initially described, with (false) it is faling everywhere, on simple command like:

    GraphTraversal<Vertex, Vertex> t = g.V().hasLabel(label).has(property, value);

if (t.hasNext()) {  // java.lang.ClassCastException: java.lang.String cannot be cast to org.apache.tinkerpop.gremlin.process.remote.traversal.RemoteTraverser

so for serializeResultToString(true), all is fine, except "gv().properties()",...  somehow we have good driver config for remote access.

Regards, Chris





Hi Chris,

Hard to interpret your report. It maybe worthwhile to try the documented way of remote connection with traversal.withRemote(...) or Cluster.open(...):


There should be no need to instantiate serializer objects yourself.

Best wishes,    Marc