You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tinkerpop.apache.org by "ASF GitHub Bot (Jira)" <ji...@apache.org> on 2021/03/11 16:00:06 UTC

[jira] [Commented] (TINKERPOP-2531) Gremlin .NET driver ConnectionPool can remain without connections if server is down for 1-2 minutes

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

ASF GitHub Bot commented on TINKERPOP-2531:
-------------------------------------------

radu-iviniciu opened a new pull request #1404:
URL: https://github.com/apache/tinkerpop/pull/1404


   Link to Jira ticket: https://issues.apache.org/jira/browse/TINKERPOP-2531
   
   DESCITPTION:
       If the server becomes unavailable for a period of time the connection pool might not be able to recreate a connection right after it closes. Even with a few retries with a backoff to recrete the connections, it might not be enough and the connections end up being removed from the _deadConnections array and never end up as valid ones in the _connections array.
   
       This change tries to account for that, and, despite the caller getting a ServerUnavailableException, if the caller chooses to continue using the GremlinClient it already has, the ConnectionPool will try to restore itself.
   
       Alternatives considered:
       - Once the server is deemed unavailable we could leave it up to the caller to handle it and potentially recreate the GremlinClient. In that case this change would not be needed and the only improvement might be to better document that ServerUnavailableException means that the connection will most likely not be restored even if the server becomes available again.
   
       Chose this approach over the alternative since it seems like a feature that a ConnectionPool should have. If done on the caller side it might end having to implement a logic very similar to the one in the ConnectionPool itself just centered around GremlinClients rather than websocket connections. 
   
   TESTING: 
   - Tested in our project setup with a Gremlin Client aimed at an AWS Neptune instance. Manually interrupted the connection / restarted or modified the instance to observe reconnecting behavior. 


----------------------------------------------------------------
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

For queries about this service, please contact Infrastructure at:
users@infra.apache.org


> Gremlin .NET driver ConnectionPool can remain without connections if server is down for 1-2 minutes
> ---------------------------------------------------------------------------------------------------
>
>                 Key: TINKERPOP-2531
>                 URL: https://issues.apache.org/jira/browse/TINKERPOP-2531
>             Project: TinkerPop
>          Issue Type: Bug
>    Affects Versions: 3.4.10
>            Reporter: Radu Iviniciu
>            Priority: Major
>
> We are using Gremlin .NET client to connect to AWS Neptune. 
> If the server is down for even just 1 - 2  minutes (E,.g. Instance reboot) the connection pool can remain without any healthy connections permanently even after the server comes back up again. 
> Tracked this down to here: 
> https://github.com/apache/tinkerpop/blob/60bfc90ce43567d609b1165989c1c74ce825109b/gremlin-dotnet/src/Gremlin.Net/Driver/ConnectionPool.cs#L154
> If the server was not ready yet and the connections were not restored as part of  the previous TryGetAvailableConnection then the connection pool will remain empty indefinitely and all connections are dead even after the server is back up. 
> Is this longer-ish downtime a use case the client should handle ? Or is it expected behavior and we should let the caller handle the ServerUnavailableException, potentially recreate the GremClient altogether ?  
> What do you guys think ? If this is something the client should handle I can take a stab at it and put up a PR. 
> Thank you. 



--
This message was sent by Atlassian Jira
(v8.3.4#803005)