Github user jorgebay commented on the issue:
https://github.com/apache/tinkerpop/pull/903
I think we are going deeper into the rabbit hole... looks like you are
focused on getting this one merged, if you think that's the best course of
action, I don't mind reviewing it independently.
My main concern is introducing something that doesn't tackle the issue
experienced by the user. Limiting the max amount of connections on the C# side
without request pipelining will result in very small number of possible
simultaneous requests. If later in time we fix request pipeling, with the same
settings, the driver will be acting very differently. That's why my vote is
either tackle the issues or not, and avoid half baking it.
> The Java driver waits for an available connection in that case which
needs to have less than the `maxSimultaneousUsagePerConnection` requests in
progress.
I think that's a misfeature: if a driver doesn't reject requests after a
threshold, unbounded queueing results in memory issues (OOM) that are harder to
troubleshoot than a simple exception.
Introducing a new level of queueing is generally not a good idea, it just
pushes the problem closer to the user. We need a limit, it can be as large as
we want.
FWIW from my experience, all drivers for Apache Cassandra ended up
introducing a limit.
---
