[ 
https://issues.apache.org/jira/browse/TINKERPOP-2288?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16922700#comment-16922700
 ] 

Jayanta Mondal commented on TINKERPOP-2288:
-------------------------------------------

[~Florian Hockmann]  Thanks for enumerating the options with their pros and 
cons. Option 1 indeed is not very good.

 

At this point, I am leaning towards a combination of *Option 2* and *Option 3*.

When {color:#de350b}TryGetAvailableConnection(){color} is called  the idea is 
to do the following:
 # We keep on iterating over the connections 
 # If we encounter an open connection, we return that connection.
 # If we encounter a closed connection, we start a task to replace it, add it 
to a Task List and move forward without waiting.
 # If we have finished iterating over all connections and didn’t find any open 
connection, we go back to the task list.
 # We add a timer task (with say a 15-seconds timer which can be made 
configurable), to the task list.
 # Then we do a {color:#de350b}Task.WhenAny(){color} on the task list. If it 
returns a task with an active connection we return that. Otherwise, the timer 
fires first, and we throw the 
{color:#de350b}ConnectionPoolBusyException(){color}.

 

It seems to have all the benefits we are looking for: 

1.  Quick to get a new connection 

2. Low to moderate complexity 

3. Only time, we encounter high latency to get a new connection is when all the 
existing connections are dead, which I think I reasonable. 

 

[~spmallette] : Thanks Stephen, we are still discussing the design, and will do 
the needful. 

Thanks, both for the prompt responses. Highly appreciated. 

 

> 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)

Reply via email to