[
https://issues.apache.org/jira/browse/TINKERPOP-1978?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16515659#comment-16515659
]
Florian Hockmann commented on TINKERPOP-1978:
---------------------------------------------
Thanks for the clarification [~spmallette].
Limiting the scope to only check the connection status before returning a
connection from the pool sounds like a good idea. For anything beyond that like
the retry logic, we should start a DISCUSS thread on the dev list but the
consensus seems to be already that we don't implement that right now.
{quote}and/or with a WebSocket ping
{quote}
The .NET implementation we're using does this already by default which makes
sense in my opinion as I don't really see any downsides to issuing periodic
pings.
{quote}Does `connectionPool.keepAliveInterval` remove stale connections?
{quote}
This is probably the problem here. The connections use periodic pings to check
if the connection is still open but the .NET conneciton pool right now just
returns any connection it has without ensuring that it is still open. So it
would also return a connection that was already closed. Adding a simple
{{connection.IsOpen}} check should be enough for that.
{quote}Then there's the issue of GLV-specific connection pools. Do we try to
make them on parity with the Java driver?
{quote}
I think the GLVs should ultimately reach parity with the Java driver so users
don't get "penalized" for choosing a certain language but Stephen and Jorge
already discussed a bit about this topic in TINKERPOP-1928.
> Check for Websocket connection state when retrieved from Connection Pool
> missing
> --------------------------------------------------------------------------------
>
> Key: TINKERPOP-1978
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1978
> Project: TinkerPop
> Issue Type: Bug
> Components: dotnet
> Affects Versions: 3.3.3
> Reporter: Jamilu Abubakar
> Priority: Major
>
> When retrieving a connection from the connection pool there is no check to
> see what the current connection state of the websocket is before it is used.
> This means that if the websocket were to be closed because the server
> recycled or the connection was aborted by the server since it was last used
> and its Send method were to be called the following exception would be thrown:
> {quote}Error during execution ExecuteJObjectQueryAsync method. Exception:
> System.Net.Http.WinHttpException (0x80072EFF): The connection with the server
> was terminated abnormally
> at System.Net.WebSockets.WinHttpWebSocket.SendAsync(ArraySegment`1 buffer,
> WebSocketMessageType messageType, Boolean endOfMessage, CancellationToken
> cancellationToken)
> at System.Net.WebSockets.WebSocketHandle.SendAsync(ArraySegment`1 buffer,
> WebSocketMessageType messageType, Boolean endOfMessage, CancellationToken
> cancellationToken)
> at Gremlin.Net.Driver.WebSocketConnection.<SendMessageAsync>d__5.MoveNext()
> {quote}
>
> Please add check the Websocket state before use, handle exceptions due to
> closed or aborted connections and ideally have an extensible retry handler.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
