SearchGroupsResolverInMemoryTests.testSearchTimeoutIsFailure failure

[jpountz]

https://internal-ci.elastic.co/job/elastic+x-pack-elasticsearch+5.6+multijob-windows-compatibility/2212/consoleFull

2> REPRODUCE WITH: gradlew :x-pack-elasticsearch:plugin:test -Dtests.seed=28488DDB3C12DD9F -Dtests.class=org.elasticsearch.xpack.security.authc.ldap.SearchGroupsResolverInMemoryTests -Dtests.method="testSearchTimeoutIsFailure" -Dtests.security.manager=true -Dtests.locale=en-ZA -Dtests.timezone=Etc/GMT-12
02:14:39   1> [2018-08-16T12:14:38,755][INFO ][o.e.x.s.a.l.SearchGroupsResolverInMemoryTests] [testSearchTimeoutIsFailure]: before test
02:14:39 
02:14:39 
02:14:39   1> [2018-08-16T12:14:39,515][INFO ][o.e.x.s.a.l.SearchGroupsResolverInMemoryTests] [testSearchTimeoutIsFailure]: after test
02:14:39 
02:14:39 FAILURE 0.79s J2 | SearchGroupsResolverInMemoryTests.testSearchTimeoutIsFailure <<< FAILURES!
02:14:39    > Throwable #1: junit.framework.AssertionFailedError: Expected exception ExecutionException
02:14:39    > 	at __randomizedtesting.SeedInfo.seed([28488DDB3C12DD9F:D162EF9B2CB525A9]:0)
02:14:39    > 	at org.apache.lucene.util.LuceneTestCase.expectThrows(LuceneTestCase.java:2704)
02:14:39    > 	at org.elasticsearch.xpack.security.authc.ldap.SearchGroupsResolverInMemoryTests.testSearchTimeoutIsFailure(SearchGroupsResolverInMemoryTests.java:74)
02:14:39    > 	at java.lang.Thread.run(Thread.java:748)

I am not disabling the test yet as I couldn't find a previous occurrence of this failure. Also the seed doesn't reproduce.

I'm assigning you @tvernum based on the history of this test but feel free to reassign if you are not the right person to handle it!

The test complains that the code doesn't throw an exception as expected.

[elasticmachine]

Pinging @elastic/es-security

[tvernum]

This looks like a reverse timeout problem.
We set the client to timeout after 5ms, and the server to block for 100ms, so we should get a timeout, but, it seems like it's possible for the client timeout check to get delayed so it happens after the server has responded.

I'll increase the server delay. It would be better to make it block until we know the client has failed, but I don't think the UnboundId in-memory server can do that.

[jasontedor]

@tvernum Have you made this change and have the build failures stopped?

[tvernum]

I had not made this change, but I have now raised #33410
Given how rarely we see reports of failures in this test, it make take some time to know whether the change was successful.