[
https://issues.apache.org/jira/browse/TINKERPOP-2019?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16580916#comment-16580916
]
Florian Hockmann commented on TINKERPOP-2019:
---------------------------------------------
Ok, now we're talking about two problems here, namely the
{{InvalidOperationException}} mentioned in the ticket description and now the
new problem you mention with closed connections you encounter with your retry
policy. I concentrate in this comment on the latter as I still have no idea
where the {{InvalidOperationException}} is coming from.
{quote}with a retry and now we are getting the following error; basically we
run out of pooled connections and Gremlin.Net shuts down. (Yikes!) : )
{quote}
Normally, the {{ConnectionPool}} should close all connections when it thinks
that the remote server isn't reachable but afterwards new connections should be
established when new requests arive for the driver. However, it looks like you
encountered another exception where the driver tries to close the connection
although it was already closed (probably by the server). I created
TINKERPOP-2026 for this issue.
As a possible workaround for, couldn't you simply add the
{{WebSocketException}} to your retry policy?
{quote}Also, I'm not sure if I can abstract out Cosmosdb and only work with the
Gremlin server since I don't have experience with it.
{quote}
The problem right now is that it's very hard to reason about this error you're
seeing without being able to reproduce it. When you could reproduce it with the
Gremlin Server, then we could much easier investigate this. You can simply
start the Gremlin Server [as describes in the
docs|http://tinkerpop.apache.org/docs/current/reference/#starting-gremlin-server]
and you can download it directly from [TinkerPop's
homepage|http://tinkerpop.apache.org/]. Another option would be the [new Docker
image we provide|https://hub.docker.com/r/tinkerpop/gremlin-server/]. Just note
that it's currently only available as a release candidate for version 3.2.10
(the tag is 3.2.10-rc1) which means that you have to configure Gremlin.Net for
GraphSON 2.
> Gremlin.Net.Driver.WebSocketConnection throws System.InvalidOperationException
> ------------------------------------------------------------------------------
>
> Key: TINKERPOP-2019
> URL: https://issues.apache.org/jira/browse/TINKERPOP-2019
> Project: TinkerPop
> Issue Type: Bug
> Components: dotnet
> Affects Versions: 3.3.3
> Environment: Azure App Service
> Reporter: Sami
> Priority: Critical
>
> We're getting the following {{System.InvalidOperationException}} error
> message:
> {code:c#}
> "There is already one outstanding 'SendAsync' call for this WebSocket
> instance. ReceiveAsync and SendAsync can be called simultaneously, but at
> most one outstanding operation for each of them is allowed at the same time.
> Problem Id:
> System.InvalidOperationException at
> Gremlin.Net.Driver.WebSocketConnection+<SendMessageAsync>d__5.MoveNext"{code}
>
> We get this exception sporadically and only a few times out of thousands.
> Unfortunately we have not been able to reproduce it.
>
> I understand that when dealing with web sockets, it is allowed to have only
> a single pending "send" or a single pending "receive".
>
> After looking at GitHub's WebSocketConnection class, I don't see any
> orchestration between SendMessageAsync's {{_client.SendAsync}} (currently
> line 54) and ReceiveMessageAsync's {{_client.ReceiveAsync}} (currently line
> 66).
>
> Reference Link:
>
> [https://github.com/apache/tinkerpop/blob/master/gremlin-dotnet/src/Gremlin.Net/Driver/WebSocketConnection.cs]
>
> I'm wondering if not having orchestration in the WebSocketConnection class
> to keep the single pending "send" or a single pending "receive" rule may be
> the cause.
>
> In our .NET Core web api application, we create the GremlinConnection as a
> singleton in Startup.cs and then have one central call that makes Gremlin
> calls; i.e. it's a very straightforward implementation.
>
> Startup.cs:
> {code:c#}
> public void ConfigureServices(IServiceCollection services)
> {
> //...other stuff removed for brevity
> services.AddSingleton<IGremlinConnection, GremlinConnection>();
> }{code}
>
> Reader.cs:
> {code:c#}
> public async Task<IReadOnlyCollection<dynamic>> ExecuteGremlinQuery(string
> query)
> {
> try
> {
> return await _gremlinConnection.Client.SubmitAsync<dynamic>(query);
> }
> catch (Gremlin.Net.Driver.Exceptions.ResponseException responseException)
> {
> //our error handling removed for brevity!
> }
> }{code}
>
> We use the Gremlin.Net version 3.3.3 nuget package and the
> Microsoft.NETCore.App SDK
>
> Would it be possible to identify if this is indeed a bug on Gremlin.NET?
> And if it is, any thoughts on a best-practice (temporary) work-around that
> we can implement?
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
