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 09:40:00 GMT

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

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

Github user jorgebay commented on the issue:

    https://github.com/apache/tinkerpop/pull/903
  
    > What I meant here is that the connection cannot be used again until `SendAsync` completed.
So, my suggestion for request pipelining is simply that the connection is taken out of the
pool and then returned back as soon as `SendAsync` was successfully awaited.
    
    From an API perspective, having a `Connection` method `SendAsync()` that yields the response
once its received makes perfect sense. From the internals, I think we must look it in a different
way:
    
    - The sending process is just putting it into the write queue.
    - For receiving, there should always be an outstanding call to `ws.ReceiveMessageAsync()`,
once the response is parsed, find the callback in the in-flight requests (by request id) and
invoke it.
    
    So, on the implementation side, there is no need to await for the sending process to be
finished, it just a new item in the queue. In the case the sending failed (e.g., the connection
gets closed), the mechanism is the same: find the callback and invoke it.
    
    > I just don't see what the advantage is to keep the connections in the pool while
they are in use
    
    There shouldn't be "in use" / "idle" states of a connection. The write queue is always
sending (while there are items in the queue) and there is always an outstanding call to receive
from the ws.


> 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