[
https://issues.apache.org/jira/browse/TINKERPOP-2296?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17094386#comment-17094386
]
Stephen Mallette commented on TINKERPOP-2296:
---------------------------------------------
> i mean we could iterator OptionsStrategy instance for timeout argument
> before the bytecode translation.
After some thought, I don't think of this issue as just being about the
timeout. We currently pull four different settings from {{OptionsStrategy}}
that need to go on the {{RequestMessage}} where timeout is only one of them.
While timeout and batch size are two that can be evaluated after
deserialization of the {{RequestMessage}} (maybe user agent as well), the
request id cannot. I think that we should keep this change on the driver side
and have something examine the bytecode before it is sent to extract these
settings to be properly set on the {{RequestMessage}}.
For Java the above work is done in {{DriverRemoteConnection}}. I suppose that
it could be applied in similar fashion for the other languages, though we would
have to analyze bytecode to do it. The question is whether this should be done
with a new "bytecode strategy" infrastructure or some one-off functionality to
just deal with the application of {{OptionsStategy}}. I suppose I need to think
on that for a bit. Happy to hear any thoughts on the matter.
> 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)
