Well, you could use a distributed cache like ehCache, but that sure seems like overkill for just improving unit test performance.
Ralph On Jun 26, 2014, at 1:50 PM, Matt Sicker <boa...@gmail.com> wrote: > A neat improvement to the port finder thing would be a way for it to work > over multiple JVMs. That is, it won't work reliably when you use the fork > option in surefire. The only workaround I know would be to use different > starting ports for every test (separated by about 50-100 ports perhaps?). > Kind of hard to enforce a lock or singleton across VMs without some > networking code which would get a bit complicated. Then again, maybe not so > much. I might try this out sometime. > > > On 26 June 2014 10:00, Gary Gregory <garydgreg...@gmail.com> wrote: > I got rid of the new finder class in favor of the existing one. If I reuse > the one from Mina it does not work due to port range issues. > > Gary > > Gary > > > -------- Original message -------- > From: Matt Sicker > Date:06/25/2014 11:02 (GMT-05:00) > To: Log4J Developers List > Subject: Re: Finding free ports > > I think AvailablePortFinder was a class I copied from Camel. > > > On 24 June 2014 23:24, Gary Gregory <garydgreg...@gmail.com> wrote: > We have two ways of finding free socket ports: > > - org.apache.logging.log4j.test.AvailablePortFinder has been around for a > while, and > - org.apache.logging.log4j.core.net.FreePortFinder which is a new class I > refactored out of a bunch of duplicate code in the Flume tests. > > We need to pick on way of doing this. FreePortFinder gets my vote because it > is simpler. > > Thoughts? > > Gary > > -- > E-Mail: garydgreg...@gmail.com | ggreg...@apache.org > Java Persistence with Hibernate, Second Edition > JUnit in Action, Second Edition > Spring Batch in Action > Blog: http://garygregory.wordpress.com > Home: http://garygregory.com/ > Tweet! http://twitter.com/GaryGregory > > > > -- > Matt Sicker <boa...@gmail.com> > > > > -- > Matt Sicker <boa...@gmail.com>
