[
https://issues.apache.org/jira/browse/TINKERPOP-2288?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16918172#comment-16918172
]
Sami edited comment on TINKERPOP-2288 at 8/28/19 11:44 PM:
-----------------------------------------------------------
Yes, it does seems like gremlinConnection.Client.NrConnections is the only
information that is accessible to log to a consumer of the library. Is that
correct?
If so, how can the data that patrice asked for be exposed in order to figure
out what's going on behind the scenes?
It would be great to have the following data available:
* Current open web socket connections in pool (or remaining available)
* Current number of in-flight requests in whichever web socket that's being
used for my query
This could then be queried & logged right before or after a call to submitting
the query (gremlinConnection.Client.Submit).
was (Author: samimajed):
Yes, it does seems as if gremlinConnection.Client.NrConnections is the only
information that is accessible to log to a consumer of the library.
So how can the data that patrice asked for be exposed in order to figure out
what's going on behind the scenes?
I'd like to know:
* Current number of in-flight requests
* Current open web socket connections in pool (or remaining available)
This would be very helpful.
> 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.3
> Environment: Gremlin.Net 3.4.3
> 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)
