I think that the changes mentioned by Jens and Bruce obviate the need to do what I was proposing.
-Kirk On Fri, Jul 29, 2016 at 3:41 PM, Bruce Schuchardt <bschucha...@pivotal.io> wrote: > I'm making another change that will help. > > One of the problems with these tests is that they will choose a random > port for a Cache Server or some other component and only use the port after > opening a cache. Doing that allows the communications/membership component > to grab two ports. AvailablePort restricts the ports it hands out to the > range [20000, 30000], so if we restrict the communications/membership > component to use ports outside of that range it will help avoid collisions. > > > Le 7/29/2016 à 3:23 PM, Nabarun Nag a écrit : > >> +1 for the retry. >> >> In my opinion, maintaining available port lists maybe hard as we move >> towards running test modules in parallel. Also maybe some non-geode entity >> may come up and pick up a port hence we will need to constantly >> refresh/update the list before/after each test run. (10000 ports needs to >> be checked as per geode getRandomWildcardBindPortNumber) >> >> >> Also for GEODE-1600 fix, DUnitLauncher now passes 0 as the port number >> while creating a locator. The system assigns it an available port number >> while staring the server rather than getting a random available port >> number >> first then asking things to be started on that port. (race conditions >> ensues ) >> >> On Fri, Jul 29, 2016 at 2:36 PM William Markito <wmark...@pivotal.io> >> wrote: >> >> Why not create a JUnit rule that returns available ports and keep track of >>> ports being used ? >>> >>> I've cloned this gist from somewhere (don't remember now) but I've >>> planning >>> to send it for discussion... >>> >>> https://gist.github.com/markito/b5be3fc570c7c7c84e6d09e064a6e898 >>> >>> Still talking about rules, I've played a bit with the TemporaryFolder >>> rule >>> and that's very useful as well, specially to clean up after test runs and >>> to avoid conflicts. >>> >>> http://junit.org/junit4/javadoc/4.12/org/junit/rules/TemporaryFolder.html >>> >>> Just my 2c >>> >>> On Fri, Jul 29, 2016 at 1:54 PM, Hitesh Khamesra < >>> hitesh...@yahoo.com.invalid> wrote: >>> >>> Is there any possibility of running multiple test same time on that >>>> machine? >>>> >>>> -Hitesh >>>> >>>> >>>> From: Kirk Lund <kl...@pivotal.io> >>>> To: geode <dev@geode.incubator.apache.org> >>>> Sent: Friday, July 29, 2016 1:21 PM >>>> Subject: Flaky tests failing with BindException >>>> >>>> Many of our flaky tests are flaky because they use AvailablePort or >>>> AvailablePortHelper to find randomly available ports. They then later >>>> >>> fail >>> >>>> with a BindException because the port is already in use by the time the >>>> test uses it. >>>> >>>> Here's a proposal for a temporary fix: >>>> >>>> The module geode-junit contains a JUnit 4 rule called RetryRule. We >>>> could >>>> modify RetryRule to only retry if a BindException (or configurable >>>> exception/s) is detected. This rule would then be dropped into every >>>> test >>>> that uses AvailablePort or AvailablePortHelper. Then if the test fails >>>> >>> with >>> >>>> a BindException, it would automatically retry (once or twice or whatever >>>> >>> we >>> >>>> decide to configure RetryRule with). If the test fails without any >>>> >>> detected >>> >>>> BindException, then it would just fail without retrying. >>>> >>>> Opinions on this? >>>> >>>> Thanks, >>>> Kirk >>>> >>>> >>>> >>>> >>>> >>> >>> -- >>> >>> ~/William >>> >>> >
