[
https://issues.apache.org/jira/browse/TINKERPOP-2288?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17044612#comment-17044612
]
Florian Hockmann commented on TINKERPOP-2288:
---------------------------------------------
{quote}second, ability to await for `Task.WhenAll(connectionCreationTasks)` in
public API
{quote}
Wouldn't you simply create a new {{GremlinClient}} for that? In that case, all
connections are created when {{new GremlinClient()}}` returns as that creates
the {{ConnectionPool}} which initializes the connections in its constructor.
{quote}Next step could be for possibility to swap one region with another. All
connections will be closed than. And all new queries will await for new
connections created. It can be next step after first. Consumers still will
control region switching.
{quote}
Can't you simply retry all requests with a different URL for another region in
an exception occurs that tells you that you have a connection problem to the
region currently used? What would Gremlin.Net need to change for that?
Overall I think that this is mostly unrelated to this issue which should be
fixed by automatically repairing closed connections. If you need additional
functionality to support switching between different Azure regions, then please
create dedicated issues for that.
> Get ConnectionPoolBusyException and then ServerUnavailableExceptions
> --------------------------------------------------------------------
>
> Key: TINKERPOP-2288
> URL: https://issues.apache.org/jira/browse/TINKERPOP-2288
> Project: TinkerPop
> Issue Type: Bug
> Components: dotnet
> Affects Versions: 3.4.1
> Environment: Gremlin.Net 3.4.1
> Microsoft.NetCore.App 2.2
> Azure Cosmos DB
> Reporter: patrice huot
> Priority: Critical
>
> I am using .Net core Gremlin API query Cosmos DB.
> From time to time we are getting an error saying that no connection is
> available and then the server become unavailable. When this is occurring we
> need to restart the server. It looks like the connections are not released
> properly and become unavailable forever.
> We have configured the pool size to 50 and the MaxInProcessPerConnection to
> 32 (Which I guess should be sufficient).
> To diagnose the issue, Is there a way to access diagnostic information on the
> connection pool in order to know how many connections are open and how many
> processes are running in each connection?
> I would like to be able to monitor the connections usage to see if they are
> about to be exhausted and to see if the number of used connections is always
> increasing or of the connection lease is release when the queries completes?
> As a work around, Is there a way we can access this information from the code
> so that I can catch those scenario and create logic that re-initiate the
> connection pool?
>
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
