[
https://issues.apache.org/jira/browse/TINKERPOP-2288?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17044729#comment-17044729
]
Dzmitry.Lahoda commented on TINKERPOP-2288:
-------------------------------------------
Yes, issues is unrelated.
But just to respond to comments. To start see what I see it is simply to remove
`PopulatePoolAsync().WaitUnwrap();` from constructor. This probably will force
task of `await PopulatePoolAsync().ConfigureAwait(false);` to be available for
being public for await. So I many threads calling recreate of client, will do
that, but only winning thread (interlocked compare exchange) will provide
PopulatePoolAsync task for other threads to await. So no need for locks or
additional primitives on reconnection.
For now I really dislike that reconnection force waits for all connections to
be created and no other way around. While I would think that client should
start getting doing calls before whole pool initialized. Kind of
GetAvailableConnection to became async. This will reduce switch time.
But all starts from making task to create connections public.
> 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)
