[
https://issues.apache.org/jira/browse/TINKERPOP-2486?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17415263#comment-17415263
]
ASF GitHub Bot commented on TINKERPOP-2486:
-------------------------------------------
simonz-bq commented on pull request #1465:
URL: https://github.com/apache/tinkerpop/pull/1465#issuecomment-919600535
I updated the connection pool logic a bit to be simpler and to solve the
load balancing issues due to race conditions.
In my opinion the change seems reasonable but there may be a side effect
that I haven't considered or figured out.
Aside from the load balancing issues, the old and new logic work as follows
for getting a connection:
1. Grab the least used connection
2. If no connection could be returned, wait for one to be available
3. If the least used connection's borrow count is higher than
`maxSimultaneousUsagePerConnection`, consider making a new connection if the
pool is not full. **Even if `maxSimultaneousUsagePerConnection`, this least
used connection is still considered a valid connection to return**
4. If the least used connection's borrow count is higher than
`maxSimultaneousUsagePerConnection` AND the least used connection has reached
it's maximum processes, wait for one to be available
5. Else, return the least used connection
The old logic allowed a connection to be grabbed even if
`maxSimultaneousUsagePerConnection` was exceeded, and only deemed it invalid if
also the maximum processes was reached.
New:
1. Grab the least used connection that is below the
`maxSimultaneousUsagePerConnection` count
2. Increment the borrow count, and if it now reaches
`maxSimultaneousUsagePerConnection`, consider creation of a new connection
3. If a least used connection could not be grabbed, then wait for one to be
available
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
> Client does not load balance requests across available connections
> ------------------------------------------------------------------
>
> Key: TINKERPOP-2486
> URL: https://issues.apache.org/jira/browse/TINKERPOP-2486
> Project: TinkerPop
> Issue Type: Bug
> Components: driver
> Affects Versions: 3.4.8, 3.4.9
> Reporter: Divij Vaidya
> Priority: Major
>
> The client does not load balance requests across connections in a threadpool
> which cause a request failing with timeout even when a connection is
> available. To verify this, the following test fails:
> {code:java}
> @Test
> public void shouldBalanceConcurrentRequestsAcrossConnections() throws
> InterruptedException {
> final int connPoolSize = 16;
> final Cluster cluster = TestClientFactory.build()
> .minConnectionPoolSize(connPoolSize)
> .maxConnectionPoolSize(connPoolSize)
> .create();
> final Client.ClusteredClient client = cluster.connect();
> client.init();
> try {
> final RequestMessage.Builder request =
> client.buildMessage(RequestMessage.build(Tokens.OPS_EVAL))
> .add(Tokens.ARGS_GREMLIN, "Thread.sleep(5000)");
> final Callable<Connection> sendQueryCallable = () ->
> client.chooseConnection(request.create());
> final List<Callable<Connection>> listOfTasks = new ArrayList<>();
> for (int i=0; i<connPoolSize; i++) {
> listOfTasks.add(sendQueryCallable);
> }
> Set<String> channels = new HashSet<>();
> final List<Future<Connection>> executorSubmitFutures =
> executorServiceForTesting.invokeAll(listOfTasks);
> executorSubmitFutures.parallelStream().map(fut -> {
> try {
> return fut.get();
> } catch (InterruptedException e) {
> e.printStackTrace();
> } catch (ExecutionException e) {
> e.printStackTrace();
> }
> return null;
> }).forEach(conn -> channels.add(conn.getChannelId()));
>
> System.out.println(channels.size());
> } finally {
> cluster.close();
> }
> }
> {code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
