Hi! I've setup elastic search for configurationGraphFactory and Bigtable, using below

In a multi node Janusgraph cluster, data modification done from one instance does not sync with others until it reaches the given expiry time (cache.db-cache-time) As per the documentation[1] it does

Hi Matt, Correct, but you should really try this out and see for yourself. Also check the janusgraph db folder after having created two graphs and see what files are created. Per graph, but you

Created https://github.com/JanusGraph/janusgraph/issues/2966 to track the streaming feature request.

Thanks Marc for the pointers to check further. The Issue was not reproduced when we brought the setup again to 3 node cluster configuration. I will keep watching and collect more details if this

Hi Umesh, No, it is not clear at all whether the issue and cassandra-4.0 are related, but generally it is not useful to report bugs regarding unsupported configurations. To dig deeper, I would be

Hi Marc, Yes, we are aware of the compatibility matrix. We are keeping an eye on issues with JG-0.6.0 + Cassandra-4.0. This combination has been running for the last 3-4 months without any issues for

Hi Umesh, On the first line of your first post you state that you use cassandra-4.0. However, support for cassandra-4.0 is still an open

Hi Marc, Graph config is as below "configuration" : { "attributes.custom.attribute1.attribute-class" : "java.util.HashMap", "attributes.custom.attribute1.serializer-class" :

Hi Marc, just to be clear. If I create Graph A and build an index on Vertex P via something like: JanusGraphManagement mgmt = graph.openManagement(); PropertyKey propP =

Hi Umesh, Can you please add the graph properties (configs) and the statements for creating the vertex labels in the graph schema (if any)? Cheers, Marc

Hi Matthew, I suppose you mean identifiers instead of indices? The identifier space is per graph. The storage backends make separate files per graph. Marc

Hi Matt, No worries, let me create an issue. You are right, g.E().hasNext() is fast, and that’s because the results are streamed. On the other hand, g.V().has(“id”, “v0”).outE().hasNext() is

Hi Boxuan, Happy to put in a request on github but still a little confused. Are we saying g.E().has('index_key', 'large_number_of_edges').hasNext() isn't streaming but should (note: g.E().hasNext()

Hi all, We faced below exception while creating vertex with custom vertex id. Issue did not reproduce steadily. Setup configuration is JG-0.6.0 + cassadra-4.0 in 3 node-single DC

Hi Matt, It will definitely be a valid and valuable feature, if we could expose the streaming capacity to end users. If I recall correctly, the low-level results are indeed streamed (it might vary

Hi Umesh, What you reported might be due to a different cause. Are you able to reproduce it steadily, and if so, could you please share the steps to reproduce the problem? It would be great if you

We faced below NPE with JG 0.6.0 while creating new vertex. Not sure if this is related but never seen this exception with earlier JG versions. java.lang.NullPointerException: null at

Hi Marc, All code and property configuration are shared in the last trail mail. I hope if we have not provided the cache properties then it means it will default false. Thanks, Pawan

Hi Boxuan, thanks for the response. Some background: I'm trying to use JG as a triplestore and importing rdf. The triple <microsoft> <rdfs:type> <company> can be modelled as V('microsoft') ->