[
https://issues.apache.org/jira/browse/TINKERPOP-1774?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16608904#comment-16608904
]
ASF GitHub Bot commented on TINKERPOP-1774:
-------------------------------------------
Github user jorgebay commented on the issue:
https://github.com/apache/tinkerpop/pull/903
> Why do you want to keep the connections in the pool when a read/write
operation is executed on them? They can't be used at that time anyway and I
think that the current design is a lot easier where a connection is taken from
the pool for the request and returned simply by disposing its `ProxyConnection`.
That's exactly why, because the connection **can** be used concurrently for
requests.
Imagine the user wants to submit 10 queries, the first of them will take
the server 100ms to send the response and the other nine will take 5ms. If you
allow the connection to send the 10 requests without waiting for the response,
the latency for the nine requests will be ~5ms. With the current approach, its
~105ms.
> I think it should be possible to implement such a request pipelining
without changing the connection pool completely.
I disagree. There is no point in having a `ProxyConnection` and a pool that
dequeues when a connection can be used concurrently.
> Gremlin .NET: Support min and max sizes in Connection pool
> ----------------------------------------------------------
>
> Key: TINKERPOP-1774
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1774
> Project: TinkerPop
> Issue Type: Improvement
> Components: dotnet
> Affects Versions: 3.2.7
> Reporter: Jorge Bay
> Assignee: Florian Hockmann
> Priority: Minor
>
> Similar to the java connection pool, we should limit the maximum amount of
> connections and start with a minimum number.
> It would also a good opportunity to remove the synchronous acquisitions of
> {{lock}} in the pool implementation.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
