Hi Vinayak,

As the link shows, the issue is an issue in TinkerPop, so it cannot be solved here. Of course, you can look for workarounds. As sending result sets of multiple hundreds of Mb is not a typical client operation, you might consider opening the graph in embedded mode, that is without using gremlin server.

Best wishes,   Marc

Hi Vinayak,

Google is your friend:

https://support.datastax.com/hc/en-us/articles/204226179-Step-by-step-instructions-for-securing-JMX-authentication-for-nodetool-utility-OpsCenter-and-JConsole

Best wishes,    Marc

Hi Naresh,

Yes, elasticsearch, I should have recognized the "painless" scripting! This can mean the following things:

• your use case is maybe unusual, would it be possible to introduce a groupby step in spark that first gathers all property updates for a vertex into one update call?
• the default value of script.max_compilations_rate may be really too low for your use case, so it is worth a try increasing it (elasticsearch docs do not discourage it). I think this should be done outside janusgraph, just using the elastic API's.
• the janusgraph code for calling elasticsearch with scripts is suboptimal; I did not investigate this other than checking for existing issues (none). This option will not help you now; if you want to create an issue on janusgraph github, please specify how your system setup is, what the update rates are, etc. You would also have to check whether your issue also holds for janusgraph 0.4.1 or 0.5.3 because 0.3.x is end of life.

Best wishes,    Marc

Hi Naresh,

I guess that the script that the error message refers to, is the script that your client executes remotely at gremlin server. You may want to study:
https://tinkerpop.apache.org/docs/current/reference/#parameterized-scripts

which, depending on how you coded the frequent updates, can dramatically diminish the time spent on script compilation by gremlin server. This is also what the exception messages means with "use indexed, or scripts with parameters instead".

Best wishes,    Marc

Hi All,

The schema consists of A, B as nodes, and E as an edge with some other nodes and edges. 

A: 183468

B: 437317

E: 186513

Query:  g.V().has('property1', 'A').as('v1').outE().has('property1','E').as('e').inV().has('property1', 'B').as('v2').select('v1','e','v2').dedup().count()

Output: 200166

Time Taken: 1min

Query: g.V().has('property1', 'A').aggregate('v').outE().has('property1','E').aggregate('e').inV().has('property1', 'B').aggregate('v').select('v').dedup().as('vetexCount').select('e').dedup().as('edgeCount').select('vetexCount','edgeCount').by(unfold().count())

Output: ==>[vetexCount:383633,edgeCount:200166]

Time: 3.5 mins

Property1 is the index.

How can I optimize the queries because minutes of time for count query is not optimal. Please suggest different approaches. 

Thanks & Regards,

Vinayak