[
https://issues.apache.org/jira/browse/TINKERPOP-2268?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16904227#comment-16904227
]
MichaelZ commented on TINKERPOP-2268:
-------------------------------------
# yes, cosmos db.
# the reason i say client-side is that this client may disconnect from the
internet, for example, even if cosmos didn't close on its end.
# maybe there is another way than the ping to maintain a healthy pool. we can
replace the ping with a client-side 29 second non-activity timeout that
recreates the connection OR actually calls some generic, low-overhead call like
HTTP's HEAD verb...maybe Stephen knows of some such call in Gremlin. For what
it's worth I can try to find some super light call to do if we see that the
timeout on a connection is nearing the cosmos db limit. it could simply be a
cosmos db setting, not for all backends, or it could be generic enough for all
backends. one idea i had would be to send a bad query, i.e.
'g.constant('ff')', and the server would keep the socket alive, but not charge
RU.
# yes, i looked a little deeper and i see the index for round robin.
# conflict in that context = race condition. yes, it seems that one thing
should happen or the other, but you can check it yourself with a cosmos db and
you will see the error and its long timeout. in my experience, it's longer
than 30 seconds on cosmos' side, if that's what they are doing.
# true, as to number of connections, as long as you have enough requests per
connection, and enough time to recover a dead connection, scaling should be
efficient. the most pressing issue is the hanging. once that's fixed, you
could make the number of connections to the pool a setting too.
> Prevent Connection Failure from Hanging
> ---------------------------------------
>
> Key: TINKERPOP-2268
> URL: https://issues.apache.org/jira/browse/TINKERPOP-2268
> Project: TinkerPop
> Issue Type: Improvement
> Components: dotnet, driver
> Environment: .Net Core
> Reporter: MichaelZ
> Priority: Major
> Original Estimate: 24h
> Remaining Estimate: 24h
>
> When a consumer of the Gremlin.Net client calls to execute a Gremlin query,
> i.e. "SubmitAsync," and there is no valid connection, there will be a costly
> timeout error. I have experienced 30 to 90 second timeouts.
> I was on vacation, so I didn't do this earlier, but I have written a little
> patch that will refresh the connection pool when there is no valid
> connection, and it works flawlessly. This is quick code, and there is a more
> elegant solution, but what I did is to check IsOpen on the first connection
> snapshot, and create a new pool if it was stale. Here is is the code on the
> GremlinClient object:
> {code}
> private ConnectionPool _connectionPool; //{color:#ff0000}used to be
> readonly{color}
> // member variables
> private readonly GremlinServer _gremlinServer = null;
> private readonly GraphSONReader _graphSONReader = null;
> private readonly GraphSONWriter _graphSONWriter = null;
> private readonly string _mimeType = null;
> private readonly ConnectionPoolSettings _connectionPoolSettings = null;
> private readonly Action<ClientWebSocketOptions> _webSocketConfiguration =
> null;
> //
> public GremlinClient(GremlinServer gremlinServer, GraphSONReader
> graphSONReader = null,
> GraphSONWriter graphSONWriter = null, string mimeType = null,
> ConnectionPoolSettings connectionPoolSettings = null,
> Action<ClientWebSocketOptions> webSocketConfiguration = null)
> {
> //
> _gremlinServer = gremlinServer;
> _graphSONReader = graphSONReader;
> _graphSONWriter = graphSONWriter;
> _mimeType = mimeType;
> _connectionPoolSettings = connectionPoolSettings;
> _webSocketConfiguration = webSocketConfiguration;
> //
> {color:#ff0000}NewConnectionPool(){color};
> }
> private void NewConnectionPool()
> {
> var reader = _graphSONReader ?? new GraphSON3Reader();
> var writer = _graphSONWriter ?? new GraphSON3Writer();
> var connectionFactory = new ConnectionFactory(_gremlinServer, reader, writer,
> _mimeType ?? DefaultMimeType, _webSocketConfiguration);
> _connectionPool = new ConnectionPool(connectionFactory,
> _connectionPoolSettings ?? new ConnectionPoolSettings());
> }
> /// <summary>
> /// Provides whether the first available connection snapshot in pool is
> still open.
> /// </summary>
> {color:#ff0000}private{color} bool HasOpenConnection =>
> (bool)_connectionPool?.FirstConnectionSnapshot?.IsOpen;
> /// <inheritdoc />
> public async Task<ResultSet<T>> SubmitAsync<T>(RequestMessage requestMessage)
> {
> if (!HasOpenConnection)
> {
> Debug.WriteLine("=====================================");
> Debug.WriteLine("new connection pool");
> {color:#ff0000}NewConnectionPool(){color};
> }
> using (var connection = await
> _connectionPool.GetAvailableConnectionAsync().ConfigureAwait(false))
> { return await
> connection.SubmitAsync<T>(requestMessage).ConfigureAwait(false); }
> }
> {code}
>
--
This message was sent by Atlassian JIRA
(v7.6.14#76016)
