I’ve just brought up two test systems running RT 3.8.2 and seemingly at
random my https sessions are aborted. In the browser, after clicking on
a new link (and a few times logging in), drawing to the screen halts
and the progress bar stops. This indicates to me that the local system
and browser still think the tcp session is alive and well and are just
waiting for the server to finish sending the request or timeout.
On the server side, apache logs the following:
/var/log/apache2/error_log:[Thu May 14 20:43:48 2009] [crit]:
Apache2::RequestIO::rflush: (103) Software caused connection abort at
/usr/lib64/perl5/vendor_perl/5.8.8/HTML/Mason/ApacheHandler.pm line 1022
(/var/www/localhost/rt-3.8.2/bin/webmux.pl:151)
Searching the archives and google has turned up two hits. On this list,
a previous thread shortly concluded that users must be hitting the stop
button in their browsers before a request finished. I can say with
certainty that is not the case for me.
The second was an off list forum (for mod_perl I believe), where there
poster had a bit of perl that was generating the aborts. Or that was
the assumption of the responder.
So which is more likely the culprit for me: New bug in 3.8.2, or
something in the network?
For background on our setup, I’m the tester running on Ubuntu 9.04 with
Firefox 3.0.10. The only thing to note in the network layer is that
we’re running through two load balancers tracking sessions via SSLID.
The test servers were built of a recent Gentoo Stage 4 with mostly stock
ebuilds. To get 3.8.2 to compile via portage I had to modify the last
Gentoo ebuild for 3.6.7 into an overlay and update some of the
dependencies to match what rt-test-dependencies reported.
Regarding non-perl programs, Apache is 2.2.10, and I’ve built a mysql
5.0 back-end. I chose mod_perl 2.0 on a coin toss as the FAQ seemed to
indicate performance vs fastcgi was still up for debate. On that note,
is the obvious answer to rebuild with fastcgi?
Of course, I can provide more detail if required.
Any help would be much appreciated. Thanks.
-Nick Geron