Github user FlorianHockmann commented on the issue:
https://github.com/apache/tinkerpop/pull/903
Thanks for the clarification. I think I understand now how that would look
like. It is of course a nice improvement. However, I wonder what would be the
concrete advantages for the user? One advantage I can see is that it should
reduce the number of connections necessary to deal with the same amount of
requests as we wouldn't block connections while waiting on a response from the
server any more.
Do you see other advantages?
More importantly for this PR: To me, connection pipelining
([TINKERPOP-1775](https://issues.apache.org/jira/browse/TINKERPOP-1775)) seems
to be mostly unrelated to this PR. We would still need a connection pool and
that pool should still have configurable min and max sizes. Adding a setting
like _max inflight per connection_ would make the pool maybe a bit more
complicated but I think that the changes in this PR still make sense. What do
you say, @jorgebay?
---
