Bug #85301 for IO-Async-SSL: Fails often when tested in parallel

Tue May 14 21:36:59 2013 ANDK [...] cpan.org - Ticket created

Subject:

Fails often when tested in parallel

As per subject. Nearly all fails on cpentesters are due to "address already in use". If I run four tests in parallel, it is very likely that the first one succeeds and the three others fail due to this. Maybe a much longer grace period woud be sufficient to overcome this deficiency or some way of randomization of the port, not sure what is easier to implement. HTH && Thanks && Regards,

Tue Sep 10 08:23:20 2013 leonerd-cpan [...] leonerd.org.uk - Correspondence added

On Tue May 14 21:36:59 2013, ANDK wrote: Show quoted text

> As per subject. Nearly all fails on cpentesters are due to "address > already in use". If I run four tests in parallel, it is very likely > that the first one succeeds and the three others fail due to this. > > Maybe a much longer grace period woud be sufficient to overcome this > deficiency or some way of randomization of the port, not sure what is > easier to implement. > > HTH && Thanks && Regards,

I'm not sure I understand why on this one. All of the unit tests create a dynamic port by asking the kernel to allocate one; there are no hardcoded port numbers anywhere. Can you provide an example output? -- Paul Evans

Tue Sep 10 08:23:20 2013 The RT System itself - Status changed from 'new' to 'open'

Tue Sep 10 13:29:43 2013 andreas.koenig.7os6VVqR [...] franz.ak.mind.de - Correspondence added

CC:	ANDK [...] cpan.org
Subject:	Re: [rt.cpan.org #85301] Fails often when tested in parallel
Date:	Tue, 10 Sep 2013 19:29:20 +0200
To:	bug-IO-Async-SSL [...] rt.cpan.org
From:	Andreas Koenig <andreas.koenig.7os6VVqR [...] franz.ak.mind.de>

"Paul Evans via RT" <bug-IO-Async-SSL@rt.cpan.org> writes: Show quoted text

> <URL: https://rt.cpan.org/Ticket/Display.html?id=85301 > > > On Tue May 14 21:36:59 2013, ANDK wrote:

>> As per subject. Nearly all fails on cpentesters are due to "address >> already in use". If I run four tests in parallel, it is very likely >> that the first one succeeds and the three others fail due to this. >> >> Maybe a much longer grace period woud be sufficient to overcome this >> deficiency or some way of randomization of the port, not sure what is >> easier to implement. >> >> HTH && Thanks && Regards,

> > I'm not sure I understand why on this one. All of the unit tests create a dynamic port by asking the kernel to allocate one; there are no hardcoded port numbers anywhere. > > Can you provide an example output?

Tue Sep 10 13:46:11 2013 ANDK [...] cpan.org - Broken in 0.10 added

Tue Sep 10 13:49:53 2013 ANDK [...] cpan.org - Broken in 0.11 added

Tue Sep 10 13:49:53 2013 ANDK [...] cpan.org - Broken in 0.12 added

Fri May 29 14:39:21 2015 leonerd-cpan [...] leonerd.org.uk - Correspondence added

On Tue May 14 21:36:59 2013, ANDK wrote: Show quoted text

> As per subject. Nearly all fails on cpentesters are due to "address > already in use". If I run four tests in parallel, it is very likely > that the first one succeeds and the three others fail due to this. > > Maybe a much longer grace period woud be sufficient to overcome this > deficiency or some way of randomization of the port, not sure what is > easier to implement. > > HTH && Thanks && Regards,

Ugh. I wonder if this is a race at starting up the openssl or socat binaries. The way those work is that they ask the kernel to allocate a port, then close the socket, and ask the binary to use that. It's possible one copy of the script races with another, and probes to find the same free port during the dead time of the first. I don't know if it's possible to ask openssl or socat to allocate a port and then have it actually *tell me* which port it opened. Needs some more investigation into those programs... -- Paul Evans

Fri May 29 14:47:18 2015 leonerd-cpan [...] leonerd.org.uk - Correspondence added

On Fri May 29 14:39:21 2015, PEVANS wrote: Show quoted text

> Needs some more investigation into those programs...

Well, socat with two -d options prints something that looks quite fragile to parse but may be good enough: $ socat -d -d TCP-LISTEN:0 STDIO 2015/05/29 19:42:49 socat[9315] N listening on AF=2 0.0.0.0:50456 openssl s_server on the other hand is far worse. It doesn't like port 0 at all: $ openssl s_server -accept 12345 -key t/privkey.pem -cert t/server.pem Using default temp DH parameters ACCEPT $ openssl s_server -accept 0 -key t/privkey.pem -cert t/server.pem getservbyname failure for 0 usage: s_server [args ...] ... -- Paul Evans