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