[
https://issues.apache.org/jira/browse/TINKERPOP-2288?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16925605#comment-16925605
]
Florian Hockmann commented on TINKERPOP-2288:
---------------------------------------------
{quote}we won't resize the connection pool, but would rather replace any dead
connection with a new one.
This way we will avoid any calls to AddRange() or TryRemove() of the
CopyOnWriteCollection class, thereby avoiding any resize and potential
concurrency issues. Do you think that might work?
{quote}
I'm not sure how you want to replace the dead connection without removing it
from the pool and adding a new one. The {{CopyOnWriteCollection}} might be
changed to offer a {{Replace}} method, but it still has to create a new copy of
the array for that.
{quote}Let me know, how your timeline looks, otherwise, I can start a pull
request on this.
{quote}
I can't say when I'll find the time to tackle this. So, if you want to
contribute and have the time to implement something here, then go ahead! I
would just expect some rounds of review comments and adjustments for a change
to a central part of the driver like this one here, but that will probably
happen no matter who does the change.
> 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.2#803003)
