tinkerpop-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "ASF GitHub Bot (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (TINKERPOP-2105) Gremlin-Python connection not returned back to the pool on exception from gremlin server
Date Mon, 31 Dec 2018 12:26:00 GMT

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

ASF GitHub Bot commented on TINKERPOP-2105:

spmallette commented on pull request #1013: TINKERPOP-2105 - connection.py - add finally to
return connection to the client pool i…
URL: https://github.com/apache/tinkerpop/pull/1013
This is an automated message from the Apache Git Service.
To respond to the message, please log on GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:

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

View raw message