[
https://issues.apache.org/jira/browse/TINKERPOP-2148?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16782710#comment-16782710
]
Florian Hockmann commented on TINKERPOP-2148:
---------------------------------------------
Looking closer at this, I think there is not much we can do here. My initial
idea here to add a dedicated counter and synchronization could not prevent the
problem completely. It would only make it slightly less probable to occur. We
would still need to iterate over all connections and cannot select one
connection until we really now that it is the least used one (so after
iterating over all).
The only option I see here to completely fix this would involve such a counter
and increase it as soon as the connection is considered as the least used one.
If another connection has less in flight connections, then we would need to
decrement the counter on the other connection again and do that for all
connections until we really have the least used one. This would make the whole
operation a lot more complicated and expensive than it should be.
I don't think that it's really worth it to follow such an approach. The better
approach is that users choose better limits for the connection pool. Only
allowing a single request per connection is really not the way the driver is
intended to work, especially if you want to perform multiple requests in
parallel. There is a reason for the default value of {{32}} maximum in process
requests per connections.
Starting with version 3.4.1, the driver will throw an exception that
communicates this also a lot better. The exception will be a
{{ConnectionPoolBusyException}} and the message will read:
{code:java}
All {poolSize} connections have reached their MaxInProcessPerConnection limit
of {maxInProcessPerConnection}. Consider increasing either the PoolSize or the
MaxInProcessPerConnection limit.
{code}
I think with such an exception message it should be clear to users that they
need to increase these limits if they want to avoid this exception.
So, I will close this as _Won't Do_ unless someone chimes in and provides good
arguments to work around this issue.
> "no connection available!" is being thrown despite lots of free connections
> ---------------------------------------------------------------------------
>
> Key: TINKERPOP-2148
> URL: https://issues.apache.org/jira/browse/TINKERPOP-2148
> Project: TinkerPop
> Issue Type: Bug
> Components: dotnet
> Affects Versions: 3.4.0
> Environment: Windows 10, C#, .NET Core, CosmosDB Graph
> Reporter: Zaoshi
> Priority: Minor
>
> I am submitting multiple graph queries in parallel but in some cases it
> starts throwing this exception:
> {{Gremlin.Net.Driver.Exceptions.NoConnectionAvailableException : no
> connection available!}}
> {{ at Gremlin.Net.Driver.ConnectionPool.GetAvailableConnectionAsync()}}
> {{ at Gremlin.Net.Driver.GremlinClient.SubmitAsync[T](RequestMessage
> requestMessage)}}
> When GremlinClient is initialized with \{PoolSize = 1,
> MaxInProcessPerConnection = 8} everything works fine, however, with
> \{PoolSize = 8, MaxInProcessPerConnection = 1} it starts throwing those
> exceptions even though this connection pool should have same throughput. I
> have tried to increase pool to \{PoolSize = 128, MaxInProcessPerConnection =
> 1} but GremlinClient started to fail even more.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
