tinkerpop-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "ASF GitHub Bot (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (TINKERPOP-1774) Gremlin .NET: Support min and max sizes in Connection pool
Date Mon, 10 Sep 2018 14:05:01 GMT

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

Mime
View raw message