[
https://issues.apache.org/jira/browse/TINKERPOP-2105?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16713897#comment-16713897
]
abrageller edited comment on TINKERPOP-2105 at 12/9/18 12:06 PM:
-----------------------------------------------------------------
[~spmallette] [~Sengupta]
Hi,
I went over the gremlin_python driver code
+gremlin_python/driver/client.py+ is responsible to create 4 connections and
allocate them (via def submitAsync(self, message, bindings=None) ) for querying
DB, allocation is a blocking operation
+gremlin_python/driver/connection.py+ is responsible to return the connection
(itself) to the client pool after the read/write operation is ended
the problem is that if there is any exception in the connection, even a legit
one (like duplicate entry in DB) the connection will not catch it so the
connection is not returned to the pool
This behavior cause the client to lose all its connections
Pull request:
[https://github.com/apache/tinkerpop/pull/1013]
Will solve the bug if the write/read op is failed with exception, but if the
connection code has another issue we can still be in a problem
Maybe, for the future, you should redesign the flow and let the client manage
the connections meaning it will return the connection to the pool and not the
connection ?
p.s. this issue was opened due to my ticket
[https://forums.aws.amazon.com/thread.jspa?threadID=294077&tstart=0]
was (Author: abrag):
[~spmallette] [~Sengupta]
Hi,
I went over the gremlin_python driver code
+gremlin_python/driver/client.py+ is responsible to create 4 connections and
allocate them (via def submitAsync(self, message, bindings=None) ) for querying
DB, allocation is a blocking operation
+gremlin_python/driver/connection.py+ is responsible to return the connection
(itself) to the client pool after the read/write operation is ended
the problem is that if there is any exception in the connection, even a legit
one (like duplicate entry in DB) the connection will not catch it so the
connection is not returned to the pool
This behavior cause the client to lose all its connections
Pool request:
[https://github.com/apache/tinkerpop/pull/1013]
Will solve the bug if the write/read op is failed with exception, but if the
connection code has another issue we can still be in a problem
Maybe, for the future, you should redesign the flow and let the client manage
the connections meaning it will return the connection to the pool and not the
connection ?
p.s. this issue was opened due to my ticket
[https://forums.aws.amazon.com/thread.jspa?threadID=294077&tstart=0]
> 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)
