You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@tinkerpop.apache.org by sp...@apache.org on 2021/04/19 16:58:26 UTC

[tinkerpop] branch travis-fix updated: TINKERPOP-2504 Fix intermittent test failures in travis.

This is an automated email from the ASF dual-hosted git repository.

spmallette pushed a commit to branch travis-fix
in repository https://gitbox.apache.org/repos/asf/tinkerpop.git


The following commit(s) were added to refs/heads/travis-fix by this push:
     new 73a8d3d  TINKERPOP-2504 Fix intermittent test failures in travis.
73a8d3d is described below

commit 73a8d3d5fb3770abac4f815ca550bf6ee3e2ca21
Author: Stephen Mallette <st...@amazon.com>
AuthorDate: Mon Apr 19 12:56:16 2021 -0400

    TINKERPOP-2504 Fix intermittent test failures in travis.
    
    This change focuses on fixing the travis issue by configuring the thread pool with enough threads to ensure tests dont hang. This change doesn't exactly address the underlying problem though where threads deadlock in the style described in the comments. Will try to deal with that separately.
---
 .../org/apache/tinkerpop/gremlin/server/TestClientFactory.java     | 7 ++++++-
 1 file changed, 6 insertions(+), 1 deletion(-)

diff --git a/gremlin-server/src/test/java/org/apache/tinkerpop/gremlin/server/TestClientFactory.java b/gremlin-server/src/test/java/org/apache/tinkerpop/gremlin/server/TestClientFactory.java
index f760442..435173f 100644
--- a/gremlin-server/src/test/java/org/apache/tinkerpop/gremlin/server/TestClientFactory.java
+++ b/gremlin-server/src/test/java/org/apache/tinkerpop/gremlin/server/TestClientFactory.java
@@ -34,7 +34,12 @@ public final class TestClientFactory {
     public static final String RESOURCE_PATH = "conf/remote-objects.yaml";
 
     public static Cluster.Builder build() {
-        return Cluster.build("localhost").port(45940);
+        // if we let low resource environments have their way with getAvailableProcessors() workerPoolSize gets set
+        // to 1 and the ClusteredClient will have trouble initializing because initializeImplementation() does a
+        // join() to wait for ConnectionPool to initialize, but ConnectionPool also schedules tasks to join() in its
+        // constructor in the same executor. If there's only one thread we get a deadlock (or perhaps some odd case
+        // where multiple hosts schedule in a similar manner to exhaust whatever the size of the workerPoolSize is)
+        return Cluster.build("localhost").port(45940).workerPoolSize(2);
     }
 
     public static Cluster open() {