Hi Scott, One idea that first came into my mind is to first collect all vertex ids, and then delete them in batch & in parallel using multi-threading. Best regards, Boxuan

Hi Eric, Could you try the following query instead? lots=g.V().hasLabel('Lot').has('name',"abc").out('lotFile').out('thxxFilePValue').values('name','parvalue’) Make sure you also enable the `query.bat

Hi Wasantha, It's great to hear that you have solved the previous problem. Regarding contributing to the community, I would suggest you create a GitHub issue first, describing the problem and your app

Hi Krishna, Sorry for the late reply. Can you try one thing: See if this config works or not. If this works, then likely the problem is not with JanusGraph. Otherwise, there might be a bug, and it wou

Hi, There are a few factors you might want to consider: 1. An increase of your transaction-wise cache and database-level cache memory usage. 2. Cassandra does not support large column value well. 100-

Hi Krishna, just want to make sure you are using a fresh 0.6.1 installation, not using any of the old config coming from 0.6.0, right?

Can you try the latest version 0.6.1? There was a bug in 0.6.0 which occurs when you have multiple hostnames and you are using a gremlin (JanusGraph) server. Best, Boxuan

Hi Krishna, are you sure you are using the right configuration? Your log suggests that you are using “127.0.0.1” as your hostname.

Thanks Marc for making it clear. @Wasantha, how did you implement your void invalidate(StaticBuffer key, List<CachableStaticBuffer> entries) method? Make sure you evict this key from your Redis cache.

Hi Wasantha, I am not familiar with the transaction scope when using a remote Gremlin server, so I could be wrong, but could you try rolling back the transaction explicitly on JG instance B? Just to m

Hi Wasantha, In your example, it looks like you didn't commit your transaction on JG instance A. Uncommitted changes are only visible to the local transaction on the local instance. Can you try commit

Hi Wasantha, It's great to see that you have made some progress. If possible, it would be awesome if you could contribute your implementation to the community! Yes, modifying `ExpirationKCVSCache` is

Hi Wasantha, A centralized cache is a good idea in many use cases. What you could do is to maintain a centralized cache by yourself. This, however, requires some changes to your application code (e.g.

The approach you proposed should work as good/bad as your original single query in theory. I would be surprised if this approach works better than your original single query, but if so, please let me

Hi Brad, I can see that your traversal is using the index index_ten1_apm_0 from the following snippet: Then, JanusGraph uses in-memory filtering to check whether the results returned by the index_ten1

Hi Brad, Can you post the profile result of both queries? You can retrieve profile results by adding `.profile()` to the end of your query. Best, Boxuan

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

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 slow if v

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 dep

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 cou