[
https://issues.apache.org/jira/browse/TINKERPOP-2288?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16926515#comment-16926515
]
Florian Hockmann commented on TINKERPOP-2288:
---------------------------------------------
{quote}I was thinking of adding a TryReplaceConnection to the
{{CopyOnWriteCollection}} class. Since it has an underlying array, we can put a
new connection in the same index of where the dead connection was sitting.
{quote}
Adding such a method is probably a good idea in this case, but I think that we
still have to create a completely new array to do this as we would otherwise
modify an array while it's being used by other threads. Those threads could
otherwise still be using a connection that we are currently replacing by a new
one. So, we should probably completely stick to the "copy-on-write" principle.
Creating a new array also doesn't really hurt as it should be quite efficient
and it's a case that shouldn't happen too often. Also, depending on the
concrete implementation, it might make sense to do this for multiple
connections at once, but that is now really an implementation detail that we
don't have to decide on in advance.
{quote}Also, we need to make sure that there will be only one Task replacing
the connection for a given index.
{quote}
Yes, that's why a limited concurrency task scheduler would be useful as it
would automatically guarantee 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.2#803003)
