Yes, that's correct, SocketCreatorFactoryJUnitTest does not actually use
any sockets. I assume some unit test that ran before it used sockets. What
I really mean to say is: (1) singletons are bad, please let's keep working
to get rid of them, (2) please be careful with unit tests -- I continue to
occasionally find a unit test that creates a full cache or touches the file
system. I'm not actually picking on SocketCreatorFactoryJUnitTest --
apologies if that was the interpretation.
On Mon, Apr 27, 2020 at 2:02 PM Bruce Schuchardt <bschucha...@pivotal.io>
wrote:
> 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
>
>
>
>
