2

What is the Best Practice for managing the GremlinClient object in C#? Is it better to create a SingleInstance (via Dependency Injection) or using Dispose on the object after each call or with a using

using (var client = new GremlinClient(...))
{
  var results = client.SubmitAsync(query);
}

Since its a Sockets connection to the server, I assumed that reusing the client was the best practice, but I've been getting this error and I haven't been able to determine the root cause.

Unable to read data from the transport connection: 
An existing connection was forcibly closed by the remote host.
David Torres
  • 165
  • 9

1 Answers1

4

The recommendation is to use just one GremlinClient object and to reuse that across your application because the client uses a connection pool so the same connection can be used again for different requests instead of having to create and tear down one connection for each request. The driver also supports request pipelining since version 3.4.0 which means that the same connection can be used for different requests in parallel which reduces the number of required connections. That can of course also only work if you reuse the client.

The problem you describe however could be caused by a bug in the Gremlin.Net driver. If you are using version 3.4.0 of Gremlin.Net, then it could be this bug that can lead to a huge number of created connections. In that case, you can avoid it by downgrading to a 3.3.5 until we release a fix with version 3.4.1. If you also see the problem in version 3.3.5, then please create an issue in TinkerPop's issue tracker to describe the problem.

There could of course also be another reason for the server to close the connection. That would need to be investigated in more depth to understand the reason, e.g., with a tool like Wireshark by inspecting the network traffic between the driver and Cosmos DB.

Florian Hockmann
  • 2,634
  • 13
  • 24
  • Thank you for the response, you nailed the problem I'm having with a huge number of connections being created. When logging to monitor GremlinClient.NrConnections it was staying steady at 4 (when using default ConnectionPoolSettings), but then would be 2158 or 14201 (some random large number) and would stay at that same number. I've put some workarounds in place for the time being and will back off to 3.3.5 as well. Thanks again. – David Torres Feb 28 '19 at 15:14
  • Any ETA on 3.4.1, I've taken quite a few dependencies on ResultSet type and StatusAttributes to monitor and measure Cosmos DB RUs. Is there a branch I could clone to test 3.4.1? – David Torres Mar 01 '19 at 21:42
  • We target mid-March for a release of 3.4.1. The release will be announced on [gremlin-users](https://groups.google.com/forum/#!forum/gremlin-users) and on [Twitter](https://twitter.com/apachetinkerpop). If you want to try it out before, then you can just build [Gremlin.Net yourself from `master`](https://github.com/apache/tinkerpop/tree/master/gremlin-dotnet) from which 3.4.1 will be released. Feedback would of course be very appreciated about whether it solves your problem or whether you encounter any other issues. – Florian Hockmann Mar 02 '19 at 10:37