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

Stephen Mallette commented on TINKERPOP-2205:
---------------------------------------------

I tried a more advanced test of the {{driver-35}} branch where I installed 
Gremlin Server and my {{ProfilingApplication}} referenced above on two separate 
systems. With this setup I'm unable to really even execute my tests without the 
whole process locking up and I'm not sure what the reasoning is. It does seem 
to have something to do with {{DefaultConnectionPool.prepareConnection()}} 
blocking indefinitely for some reason, but i'm not clear why that happens at 
this point. It could also be that the little test runner i have needs some 
additional changes on the {{driver-35}} branch...not sure. Either way, until 
this little tool is running nicely and we can more accurately assess the 
performance differences between the "old" and "new" I don't think we'll see 
this branch merging to {{master}}.

> Use one connection per request for Java client
> ----------------------------------------------
>
>                 Key: TINKERPOP-2205
>                 URL: https://issues.apache.org/jira/browse/TINKERPOP-2205
>             Project: TinkerPop
>          Issue Type: Improvement
>          Components: driver
>    Affects Versions: 3.3.6
>            Reporter: Divij Vaidya
>            Assignee: Stephen Mallette
>            Priority: Major
>              Labels: deprecation
>
> This issue is a tracking item for the conversation in the mailing list 
> [[1]|https://lists.apache.org/thread.html/77728cb77d4eab90f15680595e653ffc6055b74db29cbd4dcd5f0339@%3Cdev.tinkerpop.apache.org%3E]
>  which highlights multiple problems and shortcomings in the existing Java 
> client and proposes a design change in the client connection pooling to 
> address the same. More specifically, the problems addressed are as follows:
>  # Difficulty in configuring the client for optimum performance.
>  # Undocumented dependency of configuration parameters on each other.
>  # A bad request can impact other requests on the same channel.
>  # Host is marked as dead even if it is busy serving requests.
>  # No way to free up server resources if the client has stopped consuming 
> results.
>  # No differentiation between retriable and non-retriable exceptions from the 
> application code.
>  # Keep alive is only sent when a query is executing, which means that a 
> connection open for a very long time with no query being sent will be closed 
> by the server.
>  # Race condition if the server response reaches before result queue has been 
> registered.
>  # Unpredictable behaviour if the server sends an exception followed by a 
> genuine response for the same request.
>  # A concurrent hash map (tracking pending requests) is a point of contention 
> amongst threads.
> [1]https://lists.apache.org/thread.html/77728cb77d4eab90f15680595e653ffc6055b74db29cbd4dcd5f0339@%3Cdev.tinkerpop.apache.org%3E



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

Reply via email to