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

ASF GitHub Bot commented on TINKERPOP-1774:
-------------------------------------------

Github user FlorianHockmann commented on the issue:

    https://github.com/apache/tinkerpop/pull/903
  
    > I think implementing TINKERPOP-1774 with the current implementation of 
the pool (dequeuing) comes at a cost of introducing complexity (in particular 
AsyncAutoResetEvent).
    
    I guess that depends on whether we want to implement TINKERPOP-1775 with 
our without a `max in-flight` requests per connection as that would result in 
some connections having to wait and therefore an `AsyncAutoResetEvent` would be 
helpful again.
    Without such a limit, I wonder when we would create new connections at all. 
When we just round-robin incoming requests to connections in the pool, then 
when should a new connection be created?


> 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)

Reply via email to