[
https://issues.apache.org/jira/browse/TINKERPOP-1774?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16609256#comment-16609256
]
ASF GitHub Bot commented on TINKERPOP-1774:
-------------------------------------------
Github user jorgebay commented on the issue:
https://github.com/apache/tinkerpop/pull/903
I think we should abandon the idea about removing connections from a pool
and the `ProxyConnection`, there is no point and it's not a good pattern.
All connections in the pool are available and it's up to the pool to
balance the load (incoming send requests) between the connections not restrict
concurrent operations, at least for now.
> the connection cannot be used while it is in use
That is incorrect, the underlying transport (websocket) supports just 1
sending at a time (not 1 sending and 1 receive at a time). So we limit
concurrency **on the connection**, by sending serially all incoming send
requests. **We should never use 1 send followed by 1 receive call**, we should
send items serially and always be receiving in the background.
> 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)
