You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@geode.apache.org by Kirk Lund <kl...@pivotal.io> on 2016/02/09 22:09:53 UTC
AvailablePort.getRandomAvailablePort and CI failures
I'm seeing more and more CI failures caused by our use of
AvailablePort.getRandomAvailablePort. When the test calls
AvailablePort.getRandomAvailablePort, a random port is found. But by the
time the test actually goes to use the port it's already in use.
It doesn't really make sense to fix this one test at a time since we have a
very large number of tests doing this and hitting this failure in CI.
I believe the correct fix would be to sweep through the tests to get rid of
our use of AvailablePort.getRandomAvailablePort, use zero for the port and
then ask the server what port it ended up using if we need the port for
something.
Trying to determine a randomly available port up front before using it is
just a race condition waiting to happen.
Thoughts?
Caused by: java.net.BindException: Address already in use
at java.net.PlainSocketImpl.socketBind(Native Method)
at java.net.AbstractPlainSocketImpl.bind(AbstractPlainSocketImpl.java:387)
at java.net.ServerSocket.bind(ServerSocket.java:375)
at
com.gemstone.gemfire.internal.SocketCreator.createServerSocket(SocketCreator.java:835)
... 27 more
at junit.framework.Assert.fail(Assert.java:57)
at junit.framework.TestCase.fail(TestCase.java:227)
at dunit.DistributedTestCase.fail(DistributedTestCase.java:970)
at
com.gemstone.gemfire.security.SecurityTestUtil.createCacheServer(SecurityTestUtil.java:341)
at
com.gemstone.gemfire.security.ClientAuthorizationTestBase.createCacheServer(ClientAuthorizationTestBase.java:135)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:497)
at hydra.MethExecutor.execute(MethExecutor.java:198)
at
dunit.standalone.RemoteDUnitVM.executeMethodOnClass(RemoteDUnitVM.java:117)
at sun.reflect.GeneratedMethodAccessor210.invoke(Unknown Source)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:497)
at sun.rmi.server.UnicastServerRef.dispatch(UnicastServerRef.java:323)
at sun.rmi.transport.Transport$1.run(Transport.java:200)
at sun.rmi.transport.Transport$1.run(Transport.java:197)
at java.security.AccessController.doPrivileged(Native Method)
at sun.rmi.transport.Transport.serviceCall(Transport.java:196)
at
sun.rmi.transport.tcp.TCPTransport.handleMessages(TCPTransport.java:568)
at
sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.run0(TCPTransport.java:826)
at
sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.lambda$run$95(TCPTransport.java:683)
at java.security.AccessController.doPrivileged(Native Method)
at
sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.run(TCPTransport.java:682)
... 3 more
Re: AvailablePort.getRandomAvailablePort and CI failures
Posted by Jacob Barrett <jb...@pivotal.io>.
Yes, both. The native version of Dunit selects ports (some coming from the
driving script too) and passed them to the start scripts. Parallel tests
are tough.
On Tue, Feb 9, 2016 at 4:22 PM Dan Smith <ds...@pivotal.io> wrote:
> +1
>
> This will also help us if we ever get around to parallelizing the tests.
>
> -Dan
>
> On Tue, Feb 9, 2016 at 2:55 PM, Sai Boorlagadda <sb...@pivotal.io>
> wrote:
>
> > +1
> >
> > As setting '0' is the fix for most of the tickets that are fixed in JIRA
> > for this exception.
> >
> > Sai
> >
> > On Tue, Feb 9, 2016 at 2:39 PM, Kirk Lund <kl...@pivotal.io> wrote:
> >
> > > For the C++ client tests, are the ports being used in the Java Server
> and
> > > Locator?
> > >
> > > -Kirk
> > >
> > >
> > > On Tue, Feb 9, 2016 at 2:01 PM, Jacob Barrett <jb...@pivotal.io>
> > wrote:
> > >
> > > > +1
> > > >
> > > > I am dealing with the same issue on some tests on the C++ side that
> do
> > > the
> > > > same thing. I had planned to fix it the same way that you proposed.
> > > >
> > > > Given that there are lots of ports to configure in Geode maybe as
> those
> > > > ports are activated they should be written to a properties file in
> the
> > > > working directory next to the stats, logs, etc. After the server is
> > > started
> > > > any script or executable should be able to parse that file to find
> the
> > > > ports it needs.
> > > >
> > > > -Jake
> > > >
> > > >
> > > >
> > > >
> > > > On Tue, Feb 9, 2016 at 1:09 PM Kirk Lund <kl...@pivotal.io> wrote:
> > > >
> > > > > I'm seeing more and more CI failures caused by our use of
> > > > > AvailablePort.getRandomAvailablePort. When the test calls
> > > > > AvailablePort.getRandomAvailablePort, a random port is found. But
> by
> > > the
> > > > > time the test actually goes to use the port it's already in use.
> > > > >
> > > > > It doesn't really make sense to fix this one test at a time since
> we
> > > > have a
> > > > > very large number of tests doing this and hitting this failure in
> CI.
> > > > >
> > > > > I believe the correct fix would be to sweep through the tests to
> get
> > > rid
> > > > of
> > > > > our use of AvailablePort.getRandomAvailablePort, use zero for the
> > port
> > > > and
> > > > > then ask the server what port it ended up using if we need the port
> > for
> > > > > something.
> > > > >
> > > > > Trying to determine a randomly available port up front before using
> > it
> > > is
> > > > > just a race condition waiting to happen.
> > > > >
> > > > > Thoughts?
> > > > >
> > > > > Caused by: java.net.BindException: Address already in use
> > > > > at java.net.PlainSocketImpl.socketBind(Native Method)
> > > > > at java.net
> > > > > .AbstractPlainSocketImpl.bind(AbstractPlainSocketImpl.java:387)
> > > > > at java.net.ServerSocket.bind(ServerSocket.java:375)
> > > > > at
> > > > >
> > > > >
> > > >
> > >
> >
> com.gemstone.gemfire.internal.SocketCreator.createServerSocket(SocketCreator.java:835)
> > > > > ... 27 more
> > > > >
> > > > > at junit.framework.Assert.fail(Assert.java:57)
> > > > > at junit.framework.TestCase.fail(TestCase.java:227)
> > > > > at dunit.DistributedTestCase.fail(DistributedTestCase.java:970)
> > > > > at
> > > > >
> > > > >
> > > >
> > >
> >
> com.gemstone.gemfire.security.SecurityTestUtil.createCacheServer(SecurityTestUtil.java:341)
> > > > > at
> > > > >
> > > > >
> > > >
> > >
> >
> com.gemstone.gemfire.security.ClientAuthorizationTestBase.createCacheServer(ClientAuthorizationTestBase.java:135)
> > > > > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> > > > > at
> > > > >
> > > > >
> > > >
> > >
> >
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> > > > > at
> > > > >
> > > > >
> > > >
> > >
> >
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> > > > > at java.lang.reflect.Method.invoke(Method.java:497)
> > > > > at hydra.MethExecutor.execute(MethExecutor.java:198)
> > > > > at
> > > > >
> > > >
> > >
> >
> dunit.standalone.RemoteDUnitVM.executeMethodOnClass(RemoteDUnitVM.java:117)
> > > > > at sun.reflect.GeneratedMethodAccessor210.invoke(Unknown Source)
> > > > > at
> > > > >
> > > > >
> > > >
> > >
> >
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> > > > > at java.lang.reflect.Method.invoke(Method.java:497)
> > > > > at
> > > sun.rmi.server.UnicastServerRef.dispatch(UnicastServerRef.java:323)
> > > > > at sun.rmi.transport.Transport$1.run(Transport.java:200)
> > > > > at sun.rmi.transport.Transport$1.run(Transport.java:197)
> > > > > at java.security.AccessController.doPrivileged(Native Method)
> > > > > at sun.rmi.transport.Transport.serviceCall(Transport.java:196)
> > > > > at
> > > > >
> > >
> sun.rmi.transport.tcp.TCPTransport.handleMessages(TCPTransport.java:568)
> > > > > at
> > > > >
> > > > >
> > > >
> > >
> >
> sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.run0(TCPTransport.java:826)
> > > > > at
> > > > >
> > > > >
> > > >
> > >
> >
> sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.lambda$run$95(TCPTransport.java:683)
> > > > > at java.security.AccessController.doPrivileged(Native Method)
> > > > > at
> > > > >
> > > > >
> > > >
> > >
> >
> sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.run(TCPTransport.java:682)
> > > > > ... 3 more
> > > > >
> > > >
> > >
> >
> >
> >
> > --
> > Sai Boorlagadda
> >
>
Re: AvailablePort.getRandomAvailablePort and CI failures
Posted by Dan Smith <ds...@pivotal.io>.
+1
This will also help us if we ever get around to parallelizing the tests.
-Dan
On Tue, Feb 9, 2016 at 2:55 PM, Sai Boorlagadda <sb...@pivotal.io>
wrote:
> +1
>
> As setting '0' is the fix for most of the tickets that are fixed in JIRA
> for this exception.
>
> Sai
>
> On Tue, Feb 9, 2016 at 2:39 PM, Kirk Lund <kl...@pivotal.io> wrote:
>
> > For the C++ client tests, are the ports being used in the Java Server and
> > Locator?
> >
> > -Kirk
> >
> >
> > On Tue, Feb 9, 2016 at 2:01 PM, Jacob Barrett <jb...@pivotal.io>
> wrote:
> >
> > > +1
> > >
> > > I am dealing with the same issue on some tests on the C++ side that do
> > the
> > > same thing. I had planned to fix it the same way that you proposed.
> > >
> > > Given that there are lots of ports to configure in Geode maybe as those
> > > ports are activated they should be written to a properties file in the
> > > working directory next to the stats, logs, etc. After the server is
> > started
> > > any script or executable should be able to parse that file to find the
> > > ports it needs.
> > >
> > > -Jake
> > >
> > >
> > >
> > >
> > > On Tue, Feb 9, 2016 at 1:09 PM Kirk Lund <kl...@pivotal.io> wrote:
> > >
> > > > I'm seeing more and more CI failures caused by our use of
> > > > AvailablePort.getRandomAvailablePort. When the test calls
> > > > AvailablePort.getRandomAvailablePort, a random port is found. But by
> > the
> > > > time the test actually goes to use the port it's already in use.
> > > >
> > > > It doesn't really make sense to fix this one test at a time since we
> > > have a
> > > > very large number of tests doing this and hitting this failure in CI.
> > > >
> > > > I believe the correct fix would be to sweep through the tests to get
> > rid
> > > of
> > > > our use of AvailablePort.getRandomAvailablePort, use zero for the
> port
> > > and
> > > > then ask the server what port it ended up using if we need the port
> for
> > > > something.
> > > >
> > > > Trying to determine a randomly available port up front before using
> it
> > is
> > > > just a race condition waiting to happen.
> > > >
> > > > Thoughts?
> > > >
> > > > Caused by: java.net.BindException: Address already in use
> > > > at java.net.PlainSocketImpl.socketBind(Native Method)
> > > > at java.net
> > > > .AbstractPlainSocketImpl.bind(AbstractPlainSocketImpl.java:387)
> > > > at java.net.ServerSocket.bind(ServerSocket.java:375)
> > > > at
> > > >
> > > >
> > >
> >
> com.gemstone.gemfire.internal.SocketCreator.createServerSocket(SocketCreator.java:835)
> > > > ... 27 more
> > > >
> > > > at junit.framework.Assert.fail(Assert.java:57)
> > > > at junit.framework.TestCase.fail(TestCase.java:227)
> > > > at dunit.DistributedTestCase.fail(DistributedTestCase.java:970)
> > > > at
> > > >
> > > >
> > >
> >
> com.gemstone.gemfire.security.SecurityTestUtil.createCacheServer(SecurityTestUtil.java:341)
> > > > at
> > > >
> > > >
> > >
> >
> com.gemstone.gemfire.security.ClientAuthorizationTestBase.createCacheServer(ClientAuthorizationTestBase.java:135)
> > > > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> > > > at
> > > >
> > > >
> > >
> >
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> > > > at
> > > >
> > > >
> > >
> >
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> > > > at java.lang.reflect.Method.invoke(Method.java:497)
> > > > at hydra.MethExecutor.execute(MethExecutor.java:198)
> > > > at
> > > >
> > >
> >
> dunit.standalone.RemoteDUnitVM.executeMethodOnClass(RemoteDUnitVM.java:117)
> > > > at sun.reflect.GeneratedMethodAccessor210.invoke(Unknown Source)
> > > > at
> > > >
> > > >
> > >
> >
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> > > > at java.lang.reflect.Method.invoke(Method.java:497)
> > > > at
> > sun.rmi.server.UnicastServerRef.dispatch(UnicastServerRef.java:323)
> > > > at sun.rmi.transport.Transport$1.run(Transport.java:200)
> > > > at sun.rmi.transport.Transport$1.run(Transport.java:197)
> > > > at java.security.AccessController.doPrivileged(Native Method)
> > > > at sun.rmi.transport.Transport.serviceCall(Transport.java:196)
> > > > at
> > > >
> > sun.rmi.transport.tcp.TCPTransport.handleMessages(TCPTransport.java:568)
> > > > at
> > > >
> > > >
> > >
> >
> sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.run0(TCPTransport.java:826)
> > > > at
> > > >
> > > >
> > >
> >
> sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.lambda$run$95(TCPTransport.java:683)
> > > > at java.security.AccessController.doPrivileged(Native Method)
> > > > at
> > > >
> > > >
> > >
> >
> sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.run(TCPTransport.java:682)
> > > > ... 3 more
> > > >
> > >
> >
>
>
>
> --
> Sai Boorlagadda
>
Re: AvailablePort.getRandomAvailablePort and CI failures
Posted by Sai Boorlagadda <sb...@pivotal.io>.
+1
As setting '0' is the fix for most of the tickets that are fixed in JIRA
for this exception.
Sai
On Tue, Feb 9, 2016 at 2:39 PM, Kirk Lund <kl...@pivotal.io> wrote:
> For the C++ client tests, are the ports being used in the Java Server and
> Locator?
>
> -Kirk
>
>
> On Tue, Feb 9, 2016 at 2:01 PM, Jacob Barrett <jb...@pivotal.io> wrote:
>
> > +1
> >
> > I am dealing with the same issue on some tests on the C++ side that do
> the
> > same thing. I had planned to fix it the same way that you proposed.
> >
> > Given that there are lots of ports to configure in Geode maybe as those
> > ports are activated they should be written to a properties file in the
> > working directory next to the stats, logs, etc. After the server is
> started
> > any script or executable should be able to parse that file to find the
> > ports it needs.
> >
> > -Jake
> >
> >
> >
> >
> > On Tue, Feb 9, 2016 at 1:09 PM Kirk Lund <kl...@pivotal.io> wrote:
> >
> > > I'm seeing more and more CI failures caused by our use of
> > > AvailablePort.getRandomAvailablePort. When the test calls
> > > AvailablePort.getRandomAvailablePort, a random port is found. But by
> the
> > > time the test actually goes to use the port it's already in use.
> > >
> > > It doesn't really make sense to fix this one test at a time since we
> > have a
> > > very large number of tests doing this and hitting this failure in CI.
> > >
> > > I believe the correct fix would be to sweep through the tests to get
> rid
> > of
> > > our use of AvailablePort.getRandomAvailablePort, use zero for the port
> > and
> > > then ask the server what port it ended up using if we need the port for
> > > something.
> > >
> > > Trying to determine a randomly available port up front before using it
> is
> > > just a race condition waiting to happen.
> > >
> > > Thoughts?
> > >
> > > Caused by: java.net.BindException: Address already in use
> > > at java.net.PlainSocketImpl.socketBind(Native Method)
> > > at java.net
> > > .AbstractPlainSocketImpl.bind(AbstractPlainSocketImpl.java:387)
> > > at java.net.ServerSocket.bind(ServerSocket.java:375)
> > > at
> > >
> > >
> >
> com.gemstone.gemfire.internal.SocketCreator.createServerSocket(SocketCreator.java:835)
> > > ... 27 more
> > >
> > > at junit.framework.Assert.fail(Assert.java:57)
> > > at junit.framework.TestCase.fail(TestCase.java:227)
> > > at dunit.DistributedTestCase.fail(DistributedTestCase.java:970)
> > > at
> > >
> > >
> >
> com.gemstone.gemfire.security.SecurityTestUtil.createCacheServer(SecurityTestUtil.java:341)
> > > at
> > >
> > >
> >
> com.gemstone.gemfire.security.ClientAuthorizationTestBase.createCacheServer(ClientAuthorizationTestBase.java:135)
> > > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> > > at
> > >
> > >
> >
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> > > at
> > >
> > >
> >
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> > > at java.lang.reflect.Method.invoke(Method.java:497)
> > > at hydra.MethExecutor.execute(MethExecutor.java:198)
> > > at
> > >
> >
> dunit.standalone.RemoteDUnitVM.executeMethodOnClass(RemoteDUnitVM.java:117)
> > > at sun.reflect.GeneratedMethodAccessor210.invoke(Unknown Source)
> > > at
> > >
> > >
> >
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> > > at java.lang.reflect.Method.invoke(Method.java:497)
> > > at
> sun.rmi.server.UnicastServerRef.dispatch(UnicastServerRef.java:323)
> > > at sun.rmi.transport.Transport$1.run(Transport.java:200)
> > > at sun.rmi.transport.Transport$1.run(Transport.java:197)
> > > at java.security.AccessController.doPrivileged(Native Method)
> > > at sun.rmi.transport.Transport.serviceCall(Transport.java:196)
> > > at
> > >
> sun.rmi.transport.tcp.TCPTransport.handleMessages(TCPTransport.java:568)
> > > at
> > >
> > >
> >
> sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.run0(TCPTransport.java:826)
> > > at
> > >
> > >
> >
> sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.lambda$run$95(TCPTransport.java:683)
> > > at java.security.AccessController.doPrivileged(Native Method)
> > > at
> > >
> > >
> >
> sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.run(TCPTransport.java:682)
> > > ... 3 more
> > >
> >
>
--
Sai Boorlagadda
Re: AvailablePort.getRandomAvailablePort and CI failures
Posted by Kirk Lund <kl...@pivotal.io>.
For the C++ client tests, are the ports being used in the Java Server and
Locator?
-Kirk
On Tue, Feb 9, 2016 at 2:01 PM, Jacob Barrett <jb...@pivotal.io> wrote:
> +1
>
> I am dealing with the same issue on some tests on the C++ side that do the
> same thing. I had planned to fix it the same way that you proposed.
>
> Given that there are lots of ports to configure in Geode maybe as those
> ports are activated they should be written to a properties file in the
> working directory next to the stats, logs, etc. After the server is started
> any script or executable should be able to parse that file to find the
> ports it needs.
>
> -Jake
>
>
>
>
> On Tue, Feb 9, 2016 at 1:09 PM Kirk Lund <kl...@pivotal.io> wrote:
>
> > I'm seeing more and more CI failures caused by our use of
> > AvailablePort.getRandomAvailablePort. When the test calls
> > AvailablePort.getRandomAvailablePort, a random port is found. But by the
> > time the test actually goes to use the port it's already in use.
> >
> > It doesn't really make sense to fix this one test at a time since we
> have a
> > very large number of tests doing this and hitting this failure in CI.
> >
> > I believe the correct fix would be to sweep through the tests to get rid
> of
> > our use of AvailablePort.getRandomAvailablePort, use zero for the port
> and
> > then ask the server what port it ended up using if we need the port for
> > something.
> >
> > Trying to determine a randomly available port up front before using it is
> > just a race condition waiting to happen.
> >
> > Thoughts?
> >
> > Caused by: java.net.BindException: Address already in use
> > at java.net.PlainSocketImpl.socketBind(Native Method)
> > at java.net
> > .AbstractPlainSocketImpl.bind(AbstractPlainSocketImpl.java:387)
> > at java.net.ServerSocket.bind(ServerSocket.java:375)
> > at
> >
> >
> com.gemstone.gemfire.internal.SocketCreator.createServerSocket(SocketCreator.java:835)
> > ... 27 more
> >
> > at junit.framework.Assert.fail(Assert.java:57)
> > at junit.framework.TestCase.fail(TestCase.java:227)
> > at dunit.DistributedTestCase.fail(DistributedTestCase.java:970)
> > at
> >
> >
> com.gemstone.gemfire.security.SecurityTestUtil.createCacheServer(SecurityTestUtil.java:341)
> > at
> >
> >
> com.gemstone.gemfire.security.ClientAuthorizationTestBase.createCacheServer(ClientAuthorizationTestBase.java:135)
> > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> > at
> >
> >
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> > at
> >
> >
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> > at java.lang.reflect.Method.invoke(Method.java:497)
> > at hydra.MethExecutor.execute(MethExecutor.java:198)
> > at
> >
> dunit.standalone.RemoteDUnitVM.executeMethodOnClass(RemoteDUnitVM.java:117)
> > at sun.reflect.GeneratedMethodAccessor210.invoke(Unknown Source)
> > at
> >
> >
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> > at java.lang.reflect.Method.invoke(Method.java:497)
> > at sun.rmi.server.UnicastServerRef.dispatch(UnicastServerRef.java:323)
> > at sun.rmi.transport.Transport$1.run(Transport.java:200)
> > at sun.rmi.transport.Transport$1.run(Transport.java:197)
> > at java.security.AccessController.doPrivileged(Native Method)
> > at sun.rmi.transport.Transport.serviceCall(Transport.java:196)
> > at
> > sun.rmi.transport.tcp.TCPTransport.handleMessages(TCPTransport.java:568)
> > at
> >
> >
> sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.run0(TCPTransport.java:826)
> > at
> >
> >
> sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.lambda$run$95(TCPTransport.java:683)
> > at java.security.AccessController.doPrivileged(Native Method)
> > at
> >
> >
> sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.run(TCPTransport.java:682)
> > ... 3 more
> >
>
Re: AvailablePort.getRandomAvailablePort and CI failures
Posted by Jacob Barrett <jb...@pivotal.io>.
+1
I am dealing with the same issue on some tests on the C++ side that do the
same thing. I had planned to fix it the same way that you proposed.
Given that there are lots of ports to configure in Geode maybe as those
ports are activated they should be written to a properties file in the
working directory next to the stats, logs, etc. After the server is started
any script or executable should be able to parse that file to find the
ports it needs.
-Jake
On Tue, Feb 9, 2016 at 1:09 PM Kirk Lund <kl...@pivotal.io> wrote:
> I'm seeing more and more CI failures caused by our use of
> AvailablePort.getRandomAvailablePort. When the test calls
> AvailablePort.getRandomAvailablePort, a random port is found. But by the
> time the test actually goes to use the port it's already in use.
>
> It doesn't really make sense to fix this one test at a time since we have a
> very large number of tests doing this and hitting this failure in CI.
>
> I believe the correct fix would be to sweep through the tests to get rid of
> our use of AvailablePort.getRandomAvailablePort, use zero for the port and
> then ask the server what port it ended up using if we need the port for
> something.
>
> Trying to determine a randomly available port up front before using it is
> just a race condition waiting to happen.
>
> Thoughts?
>
> Caused by: java.net.BindException: Address already in use
> at java.net.PlainSocketImpl.socketBind(Native Method)
> at java.net
> .AbstractPlainSocketImpl.bind(AbstractPlainSocketImpl.java:387)
> at java.net.ServerSocket.bind(ServerSocket.java:375)
> at
>
> com.gemstone.gemfire.internal.SocketCreator.createServerSocket(SocketCreator.java:835)
> ... 27 more
>
> at junit.framework.Assert.fail(Assert.java:57)
> at junit.framework.TestCase.fail(TestCase.java:227)
> at dunit.DistributedTestCase.fail(DistributedTestCase.java:970)
> at
>
> com.gemstone.gemfire.security.SecurityTestUtil.createCacheServer(SecurityTestUtil.java:341)
> at
>
> com.gemstone.gemfire.security.ClientAuthorizationTestBase.createCacheServer(ClientAuthorizationTestBase.java:135)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
>
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
>
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:497)
> at hydra.MethExecutor.execute(MethExecutor.java:198)
> at
> dunit.standalone.RemoteDUnitVM.executeMethodOnClass(RemoteDUnitVM.java:117)
> at sun.reflect.GeneratedMethodAccessor210.invoke(Unknown Source)
> at
>
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:497)
> at sun.rmi.server.UnicastServerRef.dispatch(UnicastServerRef.java:323)
> at sun.rmi.transport.Transport$1.run(Transport.java:200)
> at sun.rmi.transport.Transport$1.run(Transport.java:197)
> at java.security.AccessController.doPrivileged(Native Method)
> at sun.rmi.transport.Transport.serviceCall(Transport.java:196)
> at
> sun.rmi.transport.tcp.TCPTransport.handleMessages(TCPTransport.java:568)
> at
>
> sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.run0(TCPTransport.java:826)
> at
>
> sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.lambda$run$95(TCPTransport.java:683)
> at java.security.AccessController.doPrivileged(Native Method)
> at
>
> sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.run(TCPTransport.java:682)
> ... 3 more
>