Re: Nightly Build still failing with BindExceptions

2016-09-08 Thread Dan Smith
I suspect many of these BindExceptions are caused by the test itself trying to use the same port twice, rather than something else on the box grabbing a port. I do think the long term solution is to get rid of AvailablePort. But maybe in the short term we could change it to not pick a random numbe

Re: Nightly Build still failing with BindExceptions

2016-09-07 Thread Jens Deppe
We're already using that plugin to run the distributedTest task. We have a story to also implement that for flaky tests. --Jens On Tue, Sep 6, 2016 at 9:16 PM, Sai Boorlagadda wrote: > +1 for dockerized tests. > > Most of the CI failures due to state left over are not easily reproducible. > I p

Re: Nightly Build still failing with BindExceptions

2016-09-06 Thread Sai Boorlagadda
+1 for dockerized tests. Most of the CI failures due to state left over are not easily reproducible. I prefer spending time eliminating these failures and may be dockerized tests would be the way to go. Sai On Tue, Sep 6, 2016 at 5:44 PM, Swapnil Bawaskar wrote: > To make sure this is not a pr

Re: Nightly Build still failing with BindExceptions

2016-09-06 Thread Swapnil Bawaskar
To make sure this is not a problem again, how about running the tests in their own container using something like gradle-dockerized-test-plugin[1]? If each of our test is run in its own container, we will be able to address the BindAddress as well as "state left by previous test" issue. Sure this w

Re: Nightly Build still failing with BindExceptions

2016-09-06 Thread Kirk Lund
No wonder that test is intermittently failing then. I didn't think we had any tests with hard-coded ports. I filed GEODE-1863 and Darrel picked it up. -Kirk On Tue, Sep 6, 2016 at 9:30 AM, Bruce Schuchardt wrote: > This test is not using AvailablePort. There are two test cases in this > class

Re: Nightly Build still failing with BindExceptions

2016-09-06 Thread Bruce Schuchardt
This test is not using AvailablePort. There are two test cases in this class that alway use port . Le 9/6/2016 à 8:00 AM, Anthony Baker a écrit : How could we fix AvailablePort so we don’t try to use in-use ports? Anthony On Sep 3, 2016, at 10:29 PM, Kirk Lund wrote: We're still hitti

Re: Nightly Build still failing with BindExceptions

2016-09-06 Thread Kirk Lund
Well, if java.net.PlainSocketImpl.socketBind(Native Method) could tell us what grabbed the port after we found it was free, then that would provide us with very valuable information on whether or not we could prevent this. Otherwise, AvailablePort is already selecting a not-in-use port for the tes

Re: Nightly Build still failing with BindExceptions

2016-09-06 Thread Anthony Baker
How could we fix AvailablePort so we don’t try to use in-use ports? Anthony > On Sep 3, 2016, at 10:29 PM, Kirk Lund wrote: > > We're still hitting BindExceptions in the nightly build, so I'll go ahead > and propose this again: any test that uses AvailablePort to find a random > port could be a

Nightly Build still failing with BindExceptions

2016-09-03 Thread Kirk Lund
We're still hitting BindExceptions in the nightly build, so I'll go ahead and propose this again: any test that uses AvailablePort to find a random port could be altered to automatically Retry if it encounters and fails because of java.net.BindException. Opinions? -Kirk :geode-core:integrationTes