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

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

ASF GitHub Bot commented on TINKERPOP-1774:

Github user jorgebay commented on the issue:

    > Why do you want to keep the connections in the pool when a read/write operation is
executed on them? They can't be used at that time anyway and I think that the current design
is a lot easier where a connection is taken from the pool for the request and returned simply
by disposing its `ProxyConnection`.
    That's exactly why, because the connection **can** be used concurrently for requests.
    Imagine the user wants to submit 10 queries, the first of them will take the server 100ms
to send the response and the other nine will take 5ms. If you allow the connection to send
the 10 requests without waiting for the response, the latency for the nine requests will be
~5ms. With the current approach, its ~105ms.
    > I think it should be possible to implement such a request pipelining without changing
the connection pool completely.
    I disagree. There is no point in having a `ProxyConnection` and a pool that dequeues when
a connection can be used concurrently.

> 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

View raw message