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