[
https://issues.apache.org/jira/browse/TINKERPOP-2296?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17094497#comment-17094497
]
Stephen Mallette commented on TINKERPOP-2296:
---------------------------------------------
> I do not get it about making a new "bytecode strategy"
sorry, perhaps i'm being confusing. `TraversalStrategies` analyze a
{{Traversal}} object and perform actions upon it:
https://github.com/apache/tinkerpop/blob/37e6349bb956d4f8f99e6beef9d66d3c36d166dc/gremlin-core/src/main/java/org/apache/tinkerpop/gremlin/process/traversal/TraversalStrategies.java
There is an entire class of infrastructure in existence to support that
functionality and it is a first-class operation used by providers and users to
create advanced optimizations/features.
When I refer to "bytecode strategy" I'm referring to a similar and new sort of
functionality in GLVs where we provide a general way in which to analyze and
modify a {{Bytecode}} object before it is sent to the server. In the same way
that {{TraversalStrategies}} read and modify a {{Traversal}} something like
"{{BytecodeStrategies}}" would read and modify {{Bytecode}}. This capability
would be considered a first-class function that both providers and users would
make use of to optimize {{Bytecode}} before it is sent to the server.
So, to be clear, I am not suggesting that we do "bytecode strategy" instead of
continuing to utilize {{OptionsStrategy}}. I'm saying that we should consider
whether it makes sense to develop a new first class way to analyze bytecode in
GLVs. We would then use that new first class process to develop the method to
analyze the bytecode to find the {{OptionsStrategy}} extract the settings we
need and place them on the {{RequestMessage}}. If "{{BytecodeStrategies}}" has
general applicability for other features then we should probably take this
approach, but if no other uses cases materialize at this time, then I think a
one-off modification to simply read the bytecode for {{OptionsStrategy}} can be
used to just make it all work. I hope that helps clarify what I was saying.
Thanks
> Per query timeout not working from Python
> -----------------------------------------
>
> Key: TINKERPOP-2296
> URL: https://issues.apache.org/jira/browse/TINKERPOP-2296
> Project: TinkerPop
> Issue Type: Bug
> Components: python, server
> Affects Versions: 3.4.3
> Environment: Gremlin Server 3.4.3 and GremlinPython latest
> Reporter: Kelvin R. Lawrence
> Priority: Major
>
> I had a discussion with [~spmallette] about some problems I have been running
> into trying to get per query timeouts to work using the Python GLV client. As
> best as I can tell the timeout setting just gets ignored. The query executes
> to completion taking as many seconds as needed. Stephen asked for a Jira so
> writing this up here.
> Using the air-routes data set this query can take a few seconds so should
> definitely time out at 200ms. Using the Java client the same query works
> although I had an exception when using the Binary serializer but it worked
> when using GraphSON. I don't know yet if that is relevant to this issue.
>
> {{paths = (g.V().with_('scriptEvaluationTimeout', 200).}}
> {{ has('airport', 'code', 'AUS').}}
> {{ repeat(__.out('route').simplePath()).}}
> {{ until(__.has('code', 'AGR')).}}
> {{ path().by('code').}}
> {{ limit(10).}}
> {{ toList())}}
>
> {{As a sidenote it would be nice if the Python client had an equivalent of
> the Java Tokens class so that constant variable names rather than strings
> could be used for the 'scriptEvaluationTimeout' part.}}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
