[
https://issues.apache.org/jira/browse/TINKERPOP-2369?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17111136#comment-17111136
]
Stephen Mallette commented on TINKERPOP-2369:
---------------------------------------------
I never found the issue that talked further about hooking into the close frame.
I wouldn't rule out trying it. My memory may not be perfect on that one.
Any sub-classing of {{GraphTraversalSource}} is going to get "hard" pretty fast
usually. I'm not sure what the preferred way is to fix this offhand. I'd have
to spend some time reviewing that bit of the code base to figure it out and I'm
not sure I'll have time to look at it before the end of this week.
> Connections in ConnectionPool are not replaced in background when underlying
> channel is closed
> ----------------------------------------------------------------------------------------------
>
> Key: TINKERPOP-2369
> URL: https://issues.apache.org/jira/browse/TINKERPOP-2369
> Project: TinkerPop
> Issue Type: Bug
> Components: driver
> Affects Versions: 3.4.1
> Reporter: Johannes Carlsen
> Priority: Major
>
> Hi Tinkerpop team!
>
> We are using the Gremlin Java Driver to connect to an Amazon Neptune cluster.
> We are using the IAM authentication feature provided by Neptune, which means
> that individual websocket connections are closed by the server every 36
> hours, when their credentials expire. The current implementation of the
> driver does not handle this situation well, as the Connection whose channel
> has been closed by the server remains in the ConnectionPool. The connection
> is only reported as dead and replaced when when it is later chosen by the
> LoadBalancingStrategy to server a client request, which inevitably fails when
> the connection attempts to write to the closed channel.
> A fix for this bug would cause the connection pool to be automatically
> refreshed in the background by either the keep-alive mechanism, which should
> replace a connection if a keep-alive request fails, or by adding a listener
> for the close frame being sent to the underlying channel to replace the
> connection. Without a fix, the only way to recover from a stale connection is
> to retry the request at the cluster level, which will allow the request to be
> directed to a different connection.
> I noticed a PR out for the .NET client to fix this behavior:
> [https://github.com/apache/tinkerpop/pull/1279.] We are hoping for something
> similar in the Gremlin Java Driver.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
