[GitHub] [tinkerpop] jorgebay commented on issue #1077: TINKERPOP-2135 Fix handling of closed idle connections in Gremlin.Net driver

["jorgebay (GitHub)" <gi...@apache.org>]

> What's the advantage of such a custom copy-on-write list?

Any read operation is cheap and the iterator is not affected by concurrent modifications (unlike concurrent collections). Effectively what you get is a moment-in-time view of the collection, you don't have to add special conditions to track concurrent changes.

About using a queue, IMO we shouldn't rely on that sort of behaviour here (I think we discussed a similar queue approach for the pool in https://github.com/apache/tinkerpop/pull/903):
- We should support concurrent writes to the connection, if we queue it and dequeue it, we might end up with an empty pool (at a certain time). We might need complicated logic to guard for that.
- Using a enqueuing/dequeueing from a concurrent queue is not a cheap operation when multiple threads are accessing to it. We will be introducing unnecessary overhead.
- We shouldn't iterate through all the connections when borrowing from the pool, we just need to round robin through them, sample pseudo code: 

```C#
// obtain something that is fixed for this small period of time
IList<Connection> immutableCopyOfConnections = ... 
int counter = Interlocked.Increment(ref _sharedCounter);
int index = counter % immutableCopyOfConnections.Count;
return immutableCopyOfConnections[index];
```

If we need to compare the one with least in-flight requests, we should minimize the amount of checks, for example check connections at `index` and `index+1`, instead of checking the whole list (`O(2)` vs `O(n)`).

> Do you know whether the default `TaskScheduler` would work here?

No, we will need a custom one like `LimitedConcurrencyLevelTaskScheduler`.

[ Full content available at: https://github.com/apache/tinkerpop/pull/1077 ]
This message was relayed via gitbox.apache.org for dev@tinkerpop.apache.org