TINKERPOP-3063 Fix bug in Gremlin.Net authentication for parallel requests#2522
TINKERPOP-3063 Fix bug in Gremlin.Net authentication for parallel requests#2522FlorianHockmann wants to merge 1 commit into
Conversation
Executing multiple queries in parallel could lead to authentication failures if `MaxInProcessPerConnection` is set to a value higher than `1` as the second request could then be sent to the server while the server was still waiting for the authentication challenge response from the driver for the first query. This made it necessary to set `MaxInProcessPerConnection=1` as a workaround for such scenarios which of course means that connection pooling is less efficient. Simply sending a validation request on each connection right after establishing the connection and therefore before it can be used to submit queries from the user should fix this issue. The downside of this is of course that connection establishment takes slightly longer. I think this is an acceptable trade-off even for scenarios where authentication is not used since this also validates the connection irrespective of authentication and also because this delay only occurs once right at the start of an application.
|
@FlorianHockmann Do you have any thoughts on the server side solution by @tien in #2525? If the server fix fully addresses the issue, then it should make the changes here as well as equivalent GLV changes unnecessary. |
I'm just back from vacation which is why I couldn't review the PR yet. |
|
Closing this as it was superseded by #2525 which fixes the problem on the server side so the workaround I implemented here for the .NET driver isn't needed any more. |
https://issues.apache.org/jira/browse/TINKERPOP-3063
Executing multiple queries in parallel could lead to authentication failures if
MaxInProcessPerConnectionis set to a value higher than1as the second request could then be sent to the server while the server was still waiting for the authentication challenge response from the driver for the first query.This made it necessary to set
MaxInProcessPerConnection=1as a workaround for such scenarios which of course means that connection pooling is less efficient.Simply sending a validation request on each connection right after establishing the connection and therefore before it can be used to submit queries from the user should fix this issue. The downside of this is of course that connection establishment takes slightly longer. I think this is an acceptable trade-off even for scenarios where authentication is not used since this also validates the connection irrespective of authentication and also because this delay only occurs once right at the start of an application.
VOTE +1