Martin Häusler created TINKERPOP-2903:
-----------------------------------------
Summary: Option to include detectable Traversal Timeout
Key: TINKERPOP-2903
URL: https://issues.apache.org/jira/browse/TINKERPOP-2903
Project: TinkerPop
Issue Type: New Feature
Components: language
Reporter: Martin Häusler
At the moment, it is possible to achieve a timeout with the {{timeLimit}} step.
This step will cause further elements to not be reported by the result iterator
once the time limit has been reached. That's good and should stay that way, but
I've got a different use case in mind.
What I would like to accomplish is a deadline for the traversal, and if the
deadline is reached, a dedicated exception (e.g. a subclass of
{{{}TraversalInterruptedException{}}}) should be thrown, indicating that the
query has timed out. This allows the caller to detect that the timeout has been
reached and no valid complete result is to be expected from the traversal. To
the best of my knowledge (please correct me if I'm wrong) there is currently no
clean way to accomplish this in gremlin 3.6.x.
One possibility I could envision is:
{{graph.traversal().withDeadline(someUnixEpochTimestamp).V()...}}
This should affect all traversers. If it doesn't impact performance too much,
the deadline should be checked after every step. Should that prove to be too
expensive, checking the timeout after every n-th step would also be an option.
Another way to implement this would be by using the JDK-builtin timers, letting
a timer run and setting a "timeout" boolean in the traversal context to true
which is then checked by the traversers after every step (the cost to be paid
is of course the construction of the scheduler thread, which should be reused).
In theory, this could also be achieved on the database transaction level, such
that the next access to the transaction would cause the timeout. However, if a
gremlin query is busy processing elements it has already loaded (e.g. in a
misconfigured {{repeat()}} which is running in cycles), doing the timeout on
the transaction level will have no effect.
Some vendors implement this for remote communication in vendor-specific
extensions (e.g. AWS Neptune has the "evaluationTimeout"), but I think that
this feature can (and should) be standardized.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
