[ 
https://issues.apache.org/jira/browse/TINKERPOP-1978?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16514837#comment-16514837
 ] 

Florian Hockmann commented on TINKERPOP-1978:
---------------------------------------------

Adding such a check before a connection is returned from the pool sounds like a 
good idea and is also easy to implement.

I'm not sure however about the second part you're asking for:
{quote}handle exceptions due to closed or aborted connections and ideally have 
an extensible retry handler
{quote}
When such an exception occurs then it can have completely different causes. 
Maybe only this connection was closed, but maybe the server is completely 
unavailable. In the latter case, there is really nothing meaningful the driver 
could do. So I'd say that it's better to not catch those exceptions in the 
driver and instead let the application handle them.

Regarding a possible retry handler: We would need to decide for which 
exceptions a retry makes sense which is not easy to say, especially since some 
exceptions are probably vendor specific (see also TINKERPOP-1906).

I think that the other drivers also don't implement retry policies but I'm not 
sure if that is based on a decision or whether just nobody went ahead to 
implement it. [~spmallette] could you say something about that?

> 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)

Reply via email to