Github user jorgebay commented on the issue:
https://github.com/apache/tinkerpop/pull/903
> Do you see other advantages?
It allows the client to prime the server with enough requests in order to
support maximum throughput. Considering the multithreaded asynchronous nature
of the server, there is far more advantages in request pipelining than with
multiple connections.
Considering that the server is multithreaded, you can think multiple
connections w/o request pipelining as a system using multiple threads and
blocking on each thread; being a single connection with request pipelining the
equivalent of async non-blocking code.
Additionally, supporting the same (or more) throughput with fewer
connections has the advantage of having less memory consumption and being able
to support a greater number of clients.
Regarding the relation of this ticket with TINKERPOP-1775, I think we have
2 options:
a) We see this change as an incremental improvement (which definitely is)
without considering TINKERPOP-1775.
b) We try to think now how TINKERPOP-1774 and TINKERPOP-1775 will come into
place together, regardless of which we implement first. I think the ultimate
solution would be for the pool to balance request between connections, and
without taking them out of the pool each time a request/response is issued.
I think we should take the approach in B, otherwise implementing it without
thinking of TINKERPOP-1775 might introduce unnecessary complexity (i.e: a queue
of pools that get enqueued and dequeued all the time).
---
