tinkerpop-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From FlorianHockmann <...@git.apache.org>
Subject [GitHub] tinkerpop issue #903: Gremlin.Net: Add ConnectionPool min and max sizes TINK...
Date Mon, 10 Sep 2018 11:59:27 GMT
Github user FlorianHockmann commented on the issue:

    https://github.com/apache/tinkerpop/pull/903
  
    >>What I meant here is that the connection cannot be used again until SendAsync
completed. So, my suggestion for request pipelining is simply that the connection is taken
out of the pool and then returned back as soon as SendAsync was successfully awaited.
    
    > From an API perspective, having a Connection method SendAsync() that yields the response
once its received makes perfect sense. From the internals, I think we must look it in a different
way
    
    I think we are talking about different things here. I meant that the `ClientWebSocketConnection`
should be taken out of the pool when `SendAsync` is called on it until it's awaited. Not that
it should be taken out until the response was also received. Although this might require further
changes as we currently only manage `Connections` with the `ConnectionPool` which already
abstracts sending and receiving away into the common method `SubmitAsync`.
    
    With the implementation I currently have in mind, it would look something like this:
    
    1. A request comes in
    2. A connection is taken out of the pool
    3. `SendAsync()` is called on that connection and awaited
    4. The connection is returned into the pool (and can therefore be used for the next `SendAsync()`)
    5. The request finishes as soon as the response is received (like you described with continuous
calls to `ReceiveMessageAsync()` and the invoke of the right callback).
    
    That way, we don't need a dedicated write queue and most of the connection pool can stay
as (relatively) simple as it currently is.
    
    > There shouldn't be "in use" / "idle" states of a connection.
    
    How do you want to avoid an _in use_ state when the connection cannot be used while it
is _in use_, meaning that it is currently sending a message? Your supposed write queue would
also need connections to actually send the requests. So, it would also need a similar connection
pool.
    
    Should we maybe move this discussion somewhere else, like to [our HipChat room](https://apache.hipchat.com/chat/room/2013155)?


---

Mime
View raw message