1. if you have keys to your vertices available, either vertex ids or unique values of some vertex property, you can start as many gremlin clients as your backends can handle and distribute the keys over the clients. This is the easy case, but often not applicable.
2. if there are no keys available, gremlin can only help you with a full table scan g.V(). If you have a client machine with many cores, the withComputer() step, either with or without spark-local, will help you parallelize the scan.
3. you can copy the vertex files from the storage backend and decode them offline. Decoding procedures are implicit in the janusgraph source code, but I am not aware of any library that does this for you explicitly.

I have also encountered this problem, but I have found a reliable way to reproduce.

The following query works perfectly in the gremlin console (both server and client from Janusgraph 0.6.0 distribution)

return traversal.V().has(VertexType.COMPANY.name(), CompanyWrapper.PROP_COMPANY_ID, companyId)
        .out(EdgeType.EMPLOYS.name())
        .has(WorkerWrapper.PROP_STATUS, WORKER_STATUS_APPROVED)
        .skip(offset)
        .limit(limit)
        .elementMap(properties)
        .toStream()
        .map(WorkerWrapper::of);

return traversal.V().has(VertexType.COMPANY.name(), CompanyWrapper.PROP_COMPANY_ID, companyId)
        .out(EdgeType.EMPLOYS.name())
        .has(WorkerWrapper.PROP_STATUS, WORKER_STATUS_APPROVED)
        .order()
        .by(WorkerWrapper.PROP_LAST_NAME).by(WorkerWrapper.PROP_FIRST_NAME)
        .skip(offset)
        .limit(limit)
        .elementMap(properties)
        .toStream()
        .map(WorkerWrapper::of);

• "action" node has 20K attached movies with value="a" and 20K attached movies with value="b".
• "drama" node has 10K attached movies with value="b"
• "comedy" node has 10K attached movies with value="c"

• page size 100 read 200 pages in 591453 ms - average elapsed per page 2957.265 ms - min 284 ms - max 11618 ms
• page size 1000 read 20 pages in 62293 ms - average elapsed per page 3114.65 ms - min 632 ms - max 9712 ms

Hi

You are suggesting above experiment for isolating the issue right ?


I thought about not using the CQL executor service but we are in primary stage have not done any workload tests to figure out the correct CQL driver config params.

So will prefer to have a safety net of executor service which will prevent too many parallel call to CQL driver.

And looks like someone also faced similar issue.

https://lists.lfaidata.foundation/g/janusgraph-users/topic/thread_goes_into_waiting/79937111?p=,,,20,0,0,0::recentpostdate/sticky,,,20,0,0,79937111,previd=1634107810504447777,nextid=1630650635690684483&previd=1634107810504447777&nextid=1630650635690684483

Thanks,
Sujay Bothe

Hi Tanroop,

I have also faced same issue and have posted a query about it on this channel  'GraphTraversal Thread Stuck'.

Did you found the root cause of above issue ?

Thanks,
Sujay Bothe

1. Start from a fresh janusgraph-full-0.5.3 distribution (so, with an empty db folder)
2. Run bin/janusgraph.sh start
3. Run bin/gremlin.sh and
   graph = JanusGraphFactory.open('conf/janusgraph-cql-es.properties')
   GraphOfTheGodsFactory.load(graph)
   :q
4. Run bin/janusgraph.sh stop
5. Start from a fresh janusgraph-full-0.6.0 distribution (so, with an empty db folder)
6. Copy the db folder from janusgraph-full-0.5.3/db to janusgraph-full-0.6.0
7. Set set numTokens: 4 in conf/cassandra.yaml
8. Run bin/janusgraph.sh start
9. Run bin/gremlin.sh and
   graph = JanusGraphFactory.open('conf/janusgraph-cql-es.properties')
   graph.traversal().V()