Github user FlorianHockmann commented on the issue:
https://github.com/apache/tinkerpop/pull/903
>>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.
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. (Opposed to the current implementation
where the connection will only be returned to the pool when `ReceiveAsync` was
also awaited which leads to the longer latencies.) That would lead to the same
latencies for your example and we could keep the current design of the
`ConnectionPool` with the `ProxyConnection`.
I just don't see what the advantage is to keep the connections in the pool
while they are in use (meaning that `SendAsync` or `ReceiveAsync` is currently
awaited on them) as we can't use them again in that case any way. So, it would
only make the pool more complicated without getting any performance
improvements. Or am I missing something here?
---
