Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[CI] UnicastZenPingTests.testInvalidHosts #37268

Closed
alpar-t opened this issue Jan 9, 2019 · 3 comments
Closed

[CI] UnicastZenPingTests.testInvalidHosts #37268

alpar-t opened this issue Jan 9, 2019 · 3 comments
Labels
:Distributed/Cluster Coordination Cluster formation and cluster state publication, including cluster membership and fault detection. >test-failure Triaged test failures from CI v6.7.0 v7.0.0-beta1

Comments

@alpar-t
Copy link
Contributor

alpar-t commented Jan 9, 2019

Example build failure

https://elasticsearch-ci.elastic.co/job/elastic+elasticsearch+master+release-tests/309/console

Reproduction line

does not reproduce locally

REPRODUCE WITH: ./gradlew :server:unitTest \
  -Dtests.seed=86FB7F4B57514FBE \
  -Dtests.class=org.elasticsearch.discovery.zen.UnicastZenPingTests \
  -Dtests.method="testInvalidHosts" \
  -Dtests.security.manager=true \
  -Dbuild.snapshot=false \
  -Dtests.jvm.argline="-Dbuild.snapshot=false" \
  -Dtests.locale=ar-YE \
  -Dtests.timezone=Asia/Brunei \
  -Dcompiler.java=11 \
  -Druntime.java=8

Example relevant log:

FAILURE 21.5s J2 | UnicastZenPingTests.testInvalidHosts <<< FAILURES!
   > Throwable #1: java.lang.AssertionError: 
   > Expected: a collection with size <1>
   >      but: collection size was <0>
   > 	at __randomizedtesting.SeedInfo.seed([86FB7F4B57514FBE:97CE97BE380F6D4A]:0)
   > 	at org.hamcrest.MatcherAssert.assertThat(MatcherAssert.java:20)
   > 	at org.elasticsearch.discovery.zen.UnicastZenPingTests.testInvalidHosts(UnicastZenPingTests.java:726)
   > 	at java.lang.Thread.run(Thread.java:748)

Frequency

4 times Today.

Related: #23738

@alpar-t alpar-t added >test-failure Triaged test failures from CI v7.0.0 :Distributed/Cluster Coordination Cluster formation and cluster state publication, including cluster membership and fault detection. v6.7.0 labels Jan 9, 2019
@elasticmachine
Copy link
Collaborator

Pinging @elastic/es-distributed

@dakrone
Copy link
Member

dakrone commented Jan 10, 2019

This does not appear to be a timeout issue, the code in question that fails:

        final List<TransportAddress> transportAddresses = UnicastZenPing.resolveHostsLists(
            executorService,
            logger,
            Arrays.asList("127.0.0.1:9300:9300", "127.0.0.1:9301"),
            1,
            transportService,
            TimeValue.timeValueSeconds(1));
        assertThat(transportAddresses, hasSize(1)); // only one of the two is valid and will be used

Does take a little bit of time (22 seconds), but doesn't run into the timeout error that would be thrown by resolveHostsLists. Instead it appears that the the error is valid.

ywelsch added a commit that referenced this issue Jan 11, 2019
@ywelsch
Copy link
Contributor

ywelsch commented Jan 11, 2019

This looks to be a timeout issue (can be verified by changing TimeValue.timeValueSeconds(1) to something lower such as TimeValue.timeValueMillis(1). I've pushed 4d3928d

@ywelsch ywelsch closed this as completed Jan 11, 2019
ywelsch added a commit that referenced this issue Jan 11, 2019
ywelsch added a commit that referenced this issue Jan 11, 2019
ywelsch added a commit that referenced this issue Jan 11, 2019
original-brownbear added a commit to original-brownbear/elasticsearch that referenced this issue Feb 14, 2019
* Just like elastic#37268 removing another 1s timeout, those are dangerous since they're easily exceeded by an untimely gc pause
* Closes elastic#26701
original-brownbear added a commit that referenced this issue Feb 14, 2019
* Just like #37268 removing another 1s timeout, those are dangerous since they're easily exceeded by an untimely gc pause
* Closes #26701
original-brownbear added a commit to original-brownbear/elasticsearch that referenced this issue Feb 27, 2019
* Just like elastic#37268 removing another 1s timeout, those are dangerous since they're easily exceeded by an untimely gc pause
* Closes elastic#26701
original-brownbear added a commit that referenced this issue Feb 27, 2019
* Just like #37268 removing another 1s timeout, those are dangerous since they're easily exceeded by an untimely gc pause
* Closes #26701
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
:Distributed/Cluster Coordination Cluster formation and cluster state publication, including cluster membership and fault detection. >test-failure Triaged test failures from CI v6.7.0 v7.0.0-beta1
Projects
None yet
Development

No branches or pull requests

5 participants