[tinkerpop] branch travis-fix updated (73a8d3d -> 56e4f3f)

[sp...@apache.org]

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

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


 discard 73a8d3d  TINKERPOP-2504 Fix intermittent test failures in travis.
     new 56e4f3f  TINKERPOP-2504 Fix intermittent test failures in travis.

This update added new revisions after undoing existing revisions.
That is to say, some revisions that were in the old version of the
branch are not in the new version.  This situation occurs
when a user --force pushes a change and generates a repository
containing something like this:

 * -- * -- B -- O -- O -- O   (73a8d3d)
            \
             N -- N -- N   refs/heads/travis-fix (56e4f3f)

You should already have received notification emails for all of the O
revisions, and so the following emails describe only the N revisions
from the common base, B.

Any revisions marked "omit" are not gone; other references still
refer to them.  Any revisions marked "discard" are gone forever.

The 1 revisions listed above as "new" are entirely new to this
repository and will be described in separate emails.  The revisions
listed as "add" were already present in the repository and have only
been added to this reference.


Summary of changes:
 .../java/org/apache/tinkerpop/gremlin/server/TestClientFactory.java     | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

[tinkerpop] 01/01: TINKERPOP-2504 Fix intermittent test failures in travis.

[sp...@apache.org]

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

commit 56e4f3f84eca9993089225e2f6f7cd0f01c30a9a
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..f97ca2e 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(4);
     }
 
     public static Cluster open() {