Apache/mason software caused connection abort

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

No thoughts from the crowd?

-Nick

I believe that probably it’s easier to try with FastCGI instead of
mod_perl. It’s not hard to replace one with another.On Wed, May 20, 2009 at 12:56 AM, Nick Geron ngeron@corenap.com wrote:

No thoughts from the crowd?

-Nick


http://lists.bestpractical.com/cgi-bin/mailman/listinfo/rt-users

Community help: http://wiki.bestpractical.com
Commercial support: sales@bestpractical.com

Discover RT’s hidden secrets with RT Essentials from O’Reilly Media.
Buy a copy at http://rtbook.bestpractical.com

Best regards, Ruslan.

Thanks for the info, Ruslan. I discovered I forgot to up the memory on
my VMs from a low, 256M default. I gave them 1G each, and so far it
seems the behavior has abated. I’m hoping that was the problem, but if
not, I might try a FastCGI build.

-Nick

Ruslan Zakirov wrote:

Thanks for the info, Ruslan. I discovered I forgot to up the memory on
my VMs from a low, 256M default. I gave them 1G each, and so far it
seems the behavior has abated. I’m hoping that was the problem, but if
not, I might try a FastCGI build.

This is possible. Just didn’t expect to see something like that in logs.

-Nick

Best regards, Ruslan.