You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tinkerpop.apache.org by "stephen mallette (JIRA)" <ji...@apache.org> on 2019/01/07 15:16:00 UTC
[jira] [Closed] (TINKERPOP-2105) Gremlin-Python connection not
returned back to the pool on exception from gremlin server
[ https://issues.apache.org/jira/browse/TINKERPOP-2105?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
stephen mallette closed TINKERPOP-2105.
---------------------------------------
Resolution: Fixed
Assignee: stephen mallette
Fix Version/s: 3.3.5
3.4.0
dah - missed closing this open issue before release
> 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
> Affects Versions: 3.3.4
> Reporter: Kunal
> Assignee: stephen mallette
> Priority: Major
> Fix For: 3.4.0, 3.3.5
>
> 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)