New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
IO-Socket-IP test increases running time of test suite #13541
Comments
From @jkeenanI test blead on the dromedary server several times a week with: TEST_JOBS=8 make -j8 test_harness Though I don't transcribe each test run, I have a sense of which tests ##### There was a noticeably long hang while ##### ok 1 # skip Can't connect to cpanidx.org:80 real 2m6.120s [dromedary-001:perl] 1004 $ cd t; time ./perl harness -v real 0m0.088s These files appear to have come into the core test suite today with: ##### tentatively import IO-Socket-IP for consideration Problems: I. With a running time of 2m6.120s on dromedary, Can anything be done about this file's running time? II. Since Test::Pod is not distributed with core (<aside>A good thing, Thank you very much. |
From @jkeenanSummary of my perl5 (revision 5 version 12 subversion 3) configuration: Characteristics of this binary (from libperl): |
From @leonerdOn Sun, 19 Jan 2014 15:28:14 -0800
It's quick when I run it: $ time prove -b t/31nonblocking-connect-internet.t real 0m0.318s I don't think this is CPU-spinning time. That 2 minutes is probably TCP That said, it still shouldn't take 2 minutes to fail. Maybe some odd
Ahyes - should just kill the t/99pod.t file for a core import. -- leonerd@leonerd.org.uk |
The RT System itself - Status changed from 'new' to 'open' |
From @craigberryOn Sun, Jan 19, 2014 at 5:28 PM, James E Keenan
On my 10-year-old OpenVMS I64 box (which normally takes about 2 hours $ pipe show time ; perl t/31nonblocking-connect-internet.t ; show time two seconds. Without having looked at the code, given the word |
From @jkeenanOn Sun Jan 19 15:40:32 2014, leonerd@leonerd.org.uk wrote:
Perhaps. But this is the main Perl 5 development server, donated by booking.com and maintained by Seveas. So if it has an "odd networking setup", it's probably for a good reason beyond my non-sysadmin's understanding. Thank you very much. |
From @jkeenanOn Sun Jan 19 15:43:53 2014, craig.a.berry@gmail.com wrote:
Thanks for that analysis. Are there any other situations in the test suite where a library, for its own sanity-checking, needs to test outbound connections? If so, then we may have some prior art with respect to getting this test file to do the right thing. Thank you very much. |
From perl5-porters@perl.orgJames Keenan wrote:
The first rule of portable testing should be not to assume there are The solution in this case is usually to set the timeout to a few sec- |
From perl5-porters@perl.orgI wrote:
Since the test ignores $ENV{PROXY}, it does this on my develope- $ time ./perl -Ilib cpan/IO-Socket-IP/t/31nonblocking-connect-internet.t real 1m20.383s This makes it tolerable: Inline Patchdiff --git a/cpan/IO-Socket-IP/t/31nonblocking-connect-internet.t b/cpan/IO-Socket-IP/t/31nonblocking-connect-internet.t
index b236205..8dc3ca0 100644
--- a/cpan/IO-Socket-IP/t/31nonblocking-connect-internet.t
+++ b/cpan/IO-Socket-IP/t/31nonblocking-connect-internet.t
@@ -20,6 +20,7 @@ SKIP: {
PeerHost => $test_host,
PeerPort => $test_good_port,
Type => SOCK_STREAM,
+ Timeout => 3,
) or skip "Can't connect to $test_host:$test_good_port", 5;
my $socket = IO::Socket::IP->new(
@@ -57,6 +58,7 @@ SKIP: {
PeerHost => $test_host,
PeerPort => $test_bad_port,
Type => SOCK_STREAM,
+ Timeout => 3,
) and skip "Connecting to $test_host:$test_bad_port succeeds", 4;
$! == ECONNREFUSED or skip "Connecting to $test_host:$test_bad_port doesn't give ECONNREFUSED", 4;
real 0m7.736s |
From @jkeenanOn Sun Jan 19 17:28:18 2014, perl5-porters@perl.org wrote:
+1 I confirmed that if network connections are available, the test runs quickly. On my slowest machine: ##### ok 1 - defined $socket for cpanidx.org:80 real 0m4.567s rjbs or LeoNerd or whoever is shepherding this library into core: Can you apply Father C's patch (or its moral equivalant)? That will leave only the POD test issue to be dealt with. Thank you very much. |
From @wolfsageOn Sun, Jan 19, 2014 at 9:30 PM, James E Keenan via RT
What about these? ../cpan/Archive-Tar/t/99_pod.t .................................... -- Matthew Horsfall (alh) |
From @leonerdOn Sun, 19 Jan 2014 18:30:17 -0800
That's now in my upstream source, to go in the next CPAN release. I'm loathe to make a new release just for this change though, so I'll -- leonerd@leonerd.org.uk |
From dennis@kaarsemaker.netOn zo, 2014-01-19 at 16:13 -0800, James E Keenan via RT wrote:
The only thing odd is that it doesn't have direct internet access. -- |
From @leonerdOn Mon, 20 Jan 2014 22:43:39 +0100
Oh. Then this is definitely the problem. If packets simply get dropped, connect() has no way to know this is Rejecting instead of silently blackholing would definitely make this -- leonerd@leonerd.org.uk |
From @jkeenanOn Mon Jan 20 14:32:55 2014, leonerd@leonerd.org.uk wrote:
Paul, would it be possible to get an update on the status of this ticket? Thank you very much. |
From @leonerdOn Sun, 18 May 2014 07:28:44 -0700
Uhwhat? I wasn't aware that /I/ had to do anything with it. The fault is with the firewall, silently dropping packets as if a wire -- leonerd@leonerd.org.uk |
From dennis@kaarsemaker.netOn di, 2014-05-20 at 15:14 +0100, Paul "LeoNerd" Evans wrote:
Agreed, the tests are doing what they should do. I've now added a rule -- |
From @jkeenanOn Tue May 20 07:44:54 2014, dennis@kaarsemaker.net wrote:
There has been no correspondence in this ticket since May. It appears the test suite is taking a normal amount of time to complete. So I'm marking this ticket Resolved. Thank you very much. -- |
@jkeenan - Status changed from 'open' to 'resolved' |
Migrated from rt.perl.org#121037 (status was 'resolved')
Searchable as RT121037$
The text was updated successfully, but these errors were encountered: