This seems more like it should be another call to remove all singletons. Tshe
SocketCreatorFactoryJUnitTest that failed doesn't create a socket. It just
configures a SocketCreator and then asserts that it was correctly configured.
On 4/27/20, 1:58 PM, "Kirk Lund" <kl...@pivotal.io> wrote:
This test started failing consistently on Windows (5 builds in a row so
far!):
org.apache.geode.internal.net.SocketCreatorFactoryJUnitTest >
testNewSSLConfigSSLComponentLocator FAILED
java.lang.AssertionError
at org.junit.Assert.fail(Assert.java:86)
at org.junit.Assert.assertTrue(Assert.java:41)
at org.junit.Assert.assertTrue(Assert.java:52)
at
org.apache.geode.internal.net.SocketCreatorFactoryJUnitTest.testNewSSLConfigSSLComponentLocator(SocketCreatorFactoryJUnitTest.java:106)
The method testNewSSLConfigSSLComponentLocator is the first
in SocketCreatorFactoryJUnitTest to execute. And because a previous unit
test initialized the singleton either directly or indirectly without
cleaning it up in tearDown, it pollutes the JVM for later tests. The only
later unit test that is affected seems to be SocketCreatorFactoryJUnitTest.
Now you could easily fix SocketCreatorFactoryJUnitTest by adding a new
setUp() method:
*@Before*
*public void setUp() throws Exception {*
* SocketCreatorFactory.close();*
*}*
@After
public void tearDown() throws Exception {
SocketCreatorFactory.close();
}
*This change will fix this specific symptom, but not the underlying problem
-- which is "previous unit test initialized SocketCreatorFactory without
cleaning it up". *
*You can see why it's a problem if a unit test fails to cleanup EVERYTHING
that it setup. And you can why singletons (especially internal non-User API
singletons) are so dangerous for maintaining a clean GREEN CI.*
Cheers,
Kirk
