tinkerpop-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "MichaelZ (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (TINKERPOP-2268) Prevent Connection Failure from Hanging
Date Fri, 09 Aug 2019 22:42:00 GMT

    [ 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
> }
> /// <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

View raw message