[
https://issues.apache.org/jira/browse/TINKERPOP-1774?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16607184#comment-16607184
]
ASF GitHub Bot commented on TINKERPOP-1774:
-------------------------------------------
Github user FlorianHockmann commented on the issue:
https://github.com/apache/tinkerpop/pull/903
>I think the ultimate solution would be for the pool to balance request
between connections, and without taking them out of the pool each time a
request/response is issued.
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`.
I think it should be possible to implement such a request pipelining
without changing the connection pool completely. The connections would only be
returned faster. Balancing requests between connections should also not be
necessary as the FIFO nature of the pool should already provide that without
any changes.
Another aspect we should consider here is that this PR includes breaking
changes as it adds a limit to the number of connections that can be used. That
is why I would really like this to land in 3.4.0. TINKERPOP-1775 on the other
hand can be implemented any time. So, there is no rush to implement it right
now and I'm not sure whether I will have the time to also implement that in
time for 3.4.0 as I will be OOO for ~2 weeks starting Wednesday and the 3.4.0
release date shouldn't be that far away.
Long story short, I don't think that this PR should be blocked by
TINKERPOP-1775 if that means that this PR will have to wait for TinkerPop 3.5.0
or even 4.0.0. (If you - or someone else - find the time to tackle
TINKERPOP-1775, then that's of course a different matter.)
> 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)
