Bug #50610 for Net-FluidDB: Fails correlate with byte order

Sun Oct 18 02:58:08 2009 ANDK [...] cpan.org - Ticket created

Subject:

Fails correlate with byte order

I'm sorry to see that you still have FAILs. This time it seems to be the byte order 4321 that's causing you troubles. HTH && Good luck,

Mon Oct 19 06:27:22 2009 fxn [...] hashref.com - Correspondence added

On Sun Oct 18 02:58:08 2009, ANDK wrote: Show quoted text

> I'm sorry to see that you still have FAILs. This time it seems to be the > byte order 4321 that's causing you troubles.

Thanks! I've checked the FAILs in 0.08. One of them is because I didn't require any particular version of Test::Simple, but done_testing() needs 0.87 or later. I fixed that today, to be published. But the rest seem to be timeouts from the server. In which sense do you see byte order problems there?

Mon Oct 19 06:27:22 2009 The RT System itself - Status changed from 'new' to 'open'

Mon Oct 19 15:33:10 2009 andreas.koenig.7os6VVqR [...] franz.ak.mind.de - Correspondence added

CC:	ANDK [...] cpan.org
Subject:	Re: [rt.cpan.org #50610] Fails correlate with byte order
Date:	Mon, 19 Oct 2009 21:30:58 +0200
To:	bug-Net-FluidDB [...] rt.cpan.org
From:	andreas.koenig.7os6VVqR [...] franz.ak.mind.de (Andreas J. Koenig)

Show quoted text

>>>>> On Mon, 19 Oct 2009 06:27:23 -0400, "Xavier Noria via RT" <bug-Net-FluidDB@rt.cpan.org> said:

Show quoted text

> But the rest seem to be timeouts from the server. In which sense do you see byte order > problems there?

We have only one tester with a byteorder of "4321" and he sent three FAILs. It's quite possible that the real reason has nothing to do with byte order. You can reproduce my result when you install CPAN::Testers::ParseReport and run the program ctgetreports that is included like I did in the following example. You'll get something similar to my result % /usr/local/perl-5.10-uld/bin/perl -I lib bin/ctgetreports -q meta:from -q conf:byteorder Net-FluidDB-0.08 |& grep '\[4321\]' FAIL 5634734 meta:from[cpan@so[...]dt")] conf:byteorder[4321] FAIL 5634405 meta:from[cpan@so[...]dt")] conf:byteorder[4321] FAIL 5634257 meta:from[cpan@so[...]dt")] conf:byteorder[4321] You'll even find the results on your harddisk then, as % ls -l ~/var/cpantesters/nntp-testers/{5634734,5634405,5634257} -rw-r--r-- 1 k k 11955 2009-10-18 00:16:24 /home/k/var/cpantesters/nntp-testers/5634257 -rw-r--r-- 1 k k 11858 2009-10-18 00:16:23 /home/k/var/cpantesters/nntp-testers/5634405 -rw-r--r-- 1 k k 12447 2009-10-18 00:16:23 /home/k/var/cpantesters/nntp-testers/5634734 This result made me believe that there is still a byte order issue but of course it is possible that the same environment sends a PASS in the next minute:) -- andreas

Mon Oct 19 16:48:39 2009 fxn [...] hashref.com - Correspondence added

Awesome! I didn't know ctgetreports, this is great I was going through the web interface, which is OK but this allows a better way to study the reports :). I've done some research with ctgetreports, and looks like there are also FAILs from Oliver that have empty byteorders: 5635204, and 5633551. Also, all byteorders of 87654321 and 12345678 PASS except one (5649053), but that's the one with an old Test::Simple, unrelated. There's a pattern as well, those relevant FAILs fail in the same two assertions, and they are HTTP timeouts. I think that may hint some server-side issue. Just a hypothesis. I think I'll wait a bit and see. Terry Jones was going to check the logs at the time of the suite failures in case he sees something. Thank you very much Andreas, your support is fantastic.

Tue Feb 02 07:03:33 2010 fxn [...] hashref.com - Correspondence added

Looks like indeed the pattern are timouts, or some of the stuff that makes LWP::UserAgent return a hand-crafted 500 with Internal Response. That has been observed occasionally, and in a given revision a few of them appear. For example in 0.10 was 1 out of 52. I will close this ticket by now then.

Tue Feb 02 07:04:45 2010 fxn [...] hashref.com - Status changed from 'open' to 'rejected'