Hi Marc - as usual you are on the right path. The number of edges on the nodes in question was very high, so doing any sort of query on it is slow. The query was timing out; not sure what that error m

Hi all - I'm getting the following error when executing the following query: List<Object> correlationIDsListSource = traversal.V().has("source", source).outE("correlation").has("type", type).has("rang

Thank you Marc and Boxuan - I tried using vertex cut, but it appears to lead toward graph corruption (ie zombie nodes - see thread on 'graph corruption'). Agree that I need a new approach. This proxy

Thank you Marc - I tried something like this: List<Edge> edgeList = traversal.V().has("myId", myId).inE().toList(); myId is an indexed field. This also runs out of memory if the outE() size is very la

Hi all - I'm getting the following exception: org.janusgraph.core.JanusGraphException: Could not execute operation due to backend exception at org.janusgraph.diskstorage.util.BackendOperation.execute(

Turns out that I needed to set the java.io.tmpdir somewhere other than /tmp (assuming that's the default). Not sure why exactly, but by setting JAVA_OPTIONS with: -Djava.io.tmpdir=/some/place/else The

Getting this error when trying to run Gremlin on an AWS EC2 instance - exactly like: https://issues.apache.org/jira/browse/TINKERPOP-2584?page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment

Hi Marc - yes, it takes minutes to do queries on nodes with lots of edges. Like: :> g.V().has("somevar","someVal").outE().has("indexedField","value") I believe this is because of the large partition s

I've noticed that the max partition size on Cassandra can get extremely large if you have a node with lots of edges. The max partition size on the edgestore table on a graph I'm working on is over 1GB

Thank you Kevin and Boxuan for the help on this. I was scratching my head on this and decided to blow away the graph and try again. Every-time, I built a small graph and exported to graphML for viewin

Hi all - I'm seeing this from a recent graph I built: gremlin> :> g.V(4162).valueMap() ==>{source=[DS_106], sourceName=[GDELTRecord3]} gremlin> :> g.V(4146).valueMap() ==>{source=[DS_106], sourceName=

Hi Boxuan - Cluster is a 15 node cassandra cluster: nodetool status Datacenter: datacenter1 ======================= Status=Up/Down |/ State=Normal/Leaving/Joining/Moving -- Address Load Tokens Owns Ho

One thing of note is the tablehistogram for the graphindex table: nodetool tablehistograms graphsource.graphindex graphsource/graphindex histograms Percentile Read Latency Write Latency SSTables Parti

Thank you Boxuan - the code (REST service) that is modifying the graph is being called continuously when running. A slow example looks like this: Metrics: Traversal Metrics Step Count Traversers Time

Looking for documentation on how to do profile() - do you have any? Queries like this are also slow: Edge dataSourceToCorrelationEdge = traversal.E().has("edgeID", edgeID).next(); There is an index on

Sorry for the delay. When a request comes in via REST, Quarkus creates a thread to handle it; I believe it actually comes from a thread pool. This code now does: GraphTraversalSource traversal = Stati

It's usually small; typically around 3 edges. Reading your article (https://li-boxuan.medium.com/janusgraph-deep-dive-part-3-speed-up-edge-queries-3b9eb5ba34f8). Outbound edges could be large - 100s t

Hi All - I'm seeing a performance issue with this statement in Java code: Iterator<Edge> edgeIt = vert.edges(Direction.IN); in some cases this is taking over 3 seconds to return. What can I do to bett

Thanks for all the help on this. I'm coming closer to a solution thanks to you all. Question - I've been using GraphTraversalSource to do all the adding vertices and edges to my graph. Example: GraphT

So - unsurprisingly, Boxuan is correct. Code like this: GraphTraversalSource traversal = StaticInfo.getGraph().newTransaction().traversal(); try { datasourceVertex = traversal.V().has("someID", id).ne