[
https://issues.apache.org/jira/browse/TINKERPOP-1774?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16605854#comment-16605854
]
ASF GitHub Bot commented on TINKERPOP-1774:
-------------------------------------------
Github user FlorianHockmann commented on the issue:
https://github.com/apache/tinkerpop/pull/903
Thanks for the clarification. I think I understand now how that would look
like. It is of course a nice improvement. However, I wonder what would be the
concrete advantages for the user? One advantage I can see is that it should
reduce the number of connections necessary to deal with the same amount of
requests as we wouldn't block connections while waiting on a response from the
server any more.
Do you see other advantages?
More importantly for this PR: To me, connection pipelining
([TINKERPOP-1775](https://issues.apache.org/jira/browse/TINKERPOP-1775)) seems
to be mostly unrelated to this PR. We would still need a connection pool and
that pool should still have configurable min and max sizes. Adding a setting
like _max inflight per connection_ would make the pool maybe a bit more
complicated but I think that the changes in this PR still make sense. What do
you say, @jorgebay?
> 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)