[ https://issues.apache.org/jira/browse/TINKERPOP-2288?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17075084#comment-17075084 ]
Aleksandr Popitich commented on TINKERPOP-2288: ----------------------------------------------- Hi [~Florian Hockmann] I can confirm that your fix for connections recycling works correctly. I didn't observe any ServerUnavailableExceptions and ConnectionPoolBusyException exceptions for two days. The same sandbox but with previous version of Gremlin.NET throws ServerUnavailableExceptions after 12 hours of downtime. > 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 > Attachments: Gremlin.Net.3.4.7-SNAPSHOT.nupkg > > > 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)