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
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
+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
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
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
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
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
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
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