You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@tinkerpop.apache.org by GitBox <gi...@apache.org> on 2019/06/19 05:43:37 UTC

[GitHub] [tinkerpop] divijvaidya commented on issue #1146: TINKERPOP-2248 Force replacement of connections on certain errors

divijvaidya commented on issue #1146: TINKERPOP-2248 Force replacement of connections on certain errors
URL: https://github.com/apache/tinkerpop/pull/1146#issuecomment-503415064
 
 
   +1 The change looks good and should fix this issue.
   
   This is my hypothesis for what is happening:
   On CorruptedFrameException, Netty sends a CloseFrame to gracefully close the WebSocket connection asynchronously and throws the exception [1]. The exception is handled by the handler and when we check for Connection.isDead(), it is actually alive at that time waiting for the response to the CloseWebSocket frame. This same connection gets allocated to the next request and at some time it receives the response to the CloseWS frame and the handler attached to the response closes the channel, in turn, closing the second request.
   
   In the new client we plan to write for 3.5, we should handle this case in a better manner. Please note that Netty's behaviour wrt to CorruptedFrameException has changed as of 4.1.37. We need to factor that change as well in future versions [2]
   
   [1] https://github.com/netty/netty/blob/netty-4.0.56.Final/codec-http/src/main/java/io/netty/handler/codec/http/websocketx/WebSocket08FrameDecoder.java#L446
   [2] https://github.com/netty/netty/commit/7fc718db3cd52e82901dfc3fe8b437ae1ff75d4e

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


With regards,
Apache Git Services