Closed giovibal closed 5 years ago
Hi Giovanni,
Are you running Bitsy in the same VM or in a Gremlin Server connected via WebSockets?
I have seen an error like this in issue #7, but it went away once we registered BitsyIoRegistryV3d0 in the server configuration.
See:
If you have already registered past these steps, I wonder if the Gremlin console behaves differently from a plain Java interface.
Regards,
Sridhar.
No, different vm, one for gremlin-server-3.3.3 + bitzy, another with my java client. I've solved my problem with a "customized" version of bitsy, i've added register calls for VertexBean and EdgeBean classes, reinstalled bitsy to gremlin-server, and it works.
This is the new constructor of "BitsyIoRegistryV3d0" class:
private BitsyIoRegistryV3d0() {
register(GryoIo.class, UUID.class, new UUIDGryoSerializer());
register(GryoIo.class, com.lambdazen.bitsy.store.VertexBean.class, new UUIDGryoSerializer());
register(GryoIo.class, com.lambdazen.bitsy.store.EdgeBean.class, new UUIDGryoSerializer());
}
I will add a pull request asap
Thanks! I am currently traveling and will be back mid next week.
I will release 3.0.4 with your patch by the end of next week, and close this issue.
Thanks again for your help in resolving this.
Regards,
Sridhar.
Just out of curiosity, the change does not look right to me. You register UUIDGryoSerializer for both, EdgeBean and VertexBean. True, these two extend UUID, but they have much more properties added too. Did you verify, that all the data comes thru the pipe with this change? Isn't the set serializer (that handles MSB and LSB only) eating up the edge or vertex properties?
Simply put, assuming this was tested, the change does not look right to me, still.
I agree with you, I've used UUIDGryoSerializer just because VertexBean and EdgeBean extends UUID and it solved my bug with minor changes to bitsy codebase. I think that VertexBean is serialized only because there is a public "getter" in BitsyVertex, and not for any other use. I'm not an expert about gremlin serialization and wire protocol, so you can consider this patch as a "workaround" to permit the deserialization of an entire vertex from gremlin server to client.
I tried also to refactor BitsyVertex to not contain "toBean" methods and to not depends on "VertexBean" anymore, in my opinion is more correct to decouple VertexBean from BitsyVertex because they are in different application layers.
OK. Makes sense. The stuff that gets serialized needs to be carefully designed to work with Kryo.
My guess is that the Gremlin Console has some code to copy over the data to other Vertex and Edge implementations, otherwise the tests wouldn't have worked.
Can you point me to an example with a Java client that talks to a Gremlin server? I will make sure all the unit test run with this configurarion before making the release.
Regards,
Sridhar.
This is a "simplified" version of our client code who read all vertices of a graph:
ResultSet vertices = client.submit("g.V()", params);
JsonArray verticesJson = new JsonArray();
if(vertices!=null) {
vertices.iterator().forEachRemaining(vertexRS -> {
Vertex vertex = vertexRS.getVertex();
JsonObject vertexJson = new JsonObject();
Set<String> props = vertex.keys();
for (String prop : props) {
vertexJson.put(prop, vertex.property(prop).value().toString());
}
verticesJson.add(vertexJson);
});
}
Thanks. I will look at this over the weekend.
I've tried to detach VertexBean class from BitsyVertex class, but the serialization exception persists. Why VertexBean need to be serialized from gremlin-server when there is a query of type "g.V()" ?
Any updates ?
Apologies for the delay... work has been a little hectic. I will get back to you this week.
Found the culprit... https://github.com/lambdazen/bitsy/blob/6cd4d1b23568ae03c11f8d90eaa54dfcdeb3b662/src/main/java/com/lambdazen/bitsy/store/VertexBean.java#L42
The Gremlin/Kryo serializers ended up with these VertexBeans and EdgeBeans because of an optimization whereby the beans are themselves used as IDs to reduce expensive Object.equals().
Only the IDs are serialized directly by Gremlin/Kryo directly. All other classes are converted to reference classes like these:
Hence your original fix pretty much work as is. Thanks!
The only thing is that you'll have to use register the IO registry in the server yaml as follows:
serializers:
- { className: org.apache.tinkerpop.gremlin.driver.ser.GryoMessageSerializerV3d0, config: { ioRegistries: [com.lambdazen.bitsy.BitsyIoRegistryV3d0] }} # application/vnd.gremlin-v3.0+gryo
and in the client (if using Java) as follows:
GryoMapper.Builder kryoBuilder = GryoMapper.build().addRegistry(BitsyIoRegistryV3d0.instance());
MessageSerializer serializer = new GryoMessageSerializerV3d0(kryoBuilder);
Cluster.Builder builder = Cluster.build();
builder.addContactPoint("localhost"); // or other domain/IP
builder.port(8182); // or other port
builder.serializer(serializer);
Cluster cluster = builder.create();
DriverRemoteConnection remote = DriverRemoteConnection.using(cluster);
GraphTraversalSource g = EmptyGraph.instance().traversal().withRemote(remote);
// Now use g for traversals
g.V().forEachRemaining(new Consumer<Vertex>() {
public void accept(Vertex vertex) {
System.out.println("Found " + vertex.id() + " with keys " + vertex.keys() + " of class " + vertex.getClass());
}
});
I will release the next version tonight after some code cleanup.
I up'd the version 3.1.0 to account for changes to Gremlin, Jackson and NESS (thank you @cstamas )
https://oss.sonatype.org/content/groups/public/com/lambdazen/bitsy/bitsy/3.1.0/
With TP 3.3.3 and private java client, we obtain this exception when try to load Vertices:
this is my java client code, the exception is insiede "iterator().next()" and came from gremlin server:
I've tried some serialization config, but without success.