[jira] [Commented] (TINKERPOP-2105) Gremlin-Python connection not returned back to the pool on exception from gremlin server

["stephen mallette (JIRA)" <ji...@apache.org>]

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

stephen mallette commented on TINKERPOP-2105:
---------------------------------------------

I'm not sure. Can you write a test to validate that there was failing behavior and then show that the failure is resolved with this change?

> Gremlin-Python connection not returned back to the pool on exception from gremlin server
> ----------------------------------------------------------------------------------------
>
>                 Key: TINKERPOP-2105
>                 URL: https://issues.apache.org/jira/browse/TINKERPOP-2105
>             Project: TinkerPop
>          Issue Type: Bug
>          Components: driver, python
>            Reporter: Kunal
>            Priority: Major
>         Attachments: issue.py
>
>
> The is an issue with the gremlin-python driver where for requests that return an exception from the gremlin server result in the connection not being returned to the pool. I have a reproducer and have attached the code to this issue as issue.py. 
> The root cause seems to be in the error handling logic in connection.py refer to [https://github.com/apache/tinkerpop/blob/master/gremlin-python/src/main/jython/gremlin_python/driver/connection.py#L75-L81.] In exception scenarios an exception is thrown on line 77 which cause line 81 to be not executed.
> The result of this is if we use a singleton connection (as in the attached reproducer) on the client side with default pool size of 4 then the client becomes unresponsive after 4 requests that result in server throwing an exception.
> This issue is reproducible with tinkergraph reference implementation as well.
>  
> I tried a workaround by changing connection.py locally which did work for me but not sure if that would be the ideal fix. Basically in the _receive() function in connection.py I added a try finally and call the self._pool.put_nowait(self) in the finally block
>  



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)