Search code examples
apachemod-perlapache2.2mod-perl2

mod_perl2 with apache 2.22 Apache2::RequestIO::print: (103) Software caused connection abort


I’m trying to get a mod_perl2 application ported to AWS. As part of the port I thought I’d move from Debian Squeeze to Wheezy with the latest stable mod_perl & Apache2 combination.

The application works right up to the point I try and write JSON responses to the client. At this point, each request is canceled on the client and on the server I get the error

Apache2::RequestIO::print: (103) Software caused connection abort

whenever I write to the client, i.e.:

$self->req->print($output);

I’ve tried tcpdumping the response to the client, and I can see it being written out, but no response is received on the client end and it just barfs chips. I can’t find any information on how to get around this.


Solution

  • I found quite a few people asking about this question on the net without many answers. The solution to my problem was very specific but I thought I’d post what I did anyway, it may help someone.

    The client was canceling the request before the response was fully written, which was crapping out Apache::RequestIO (for reasons I still don’t know). I couldn’t work out why I was seeing this behavior.

    By using tcpdump I could see that data was being written out to the client – and it looked fine.

    By inspecting the page in Chrome and looking at the network stack, I could see that my request for data was being canceled after no response was received (which was odd because the code worked fine on other servers and I could see the response was being written). Debugging was may harder because with Apache crashing out with an error in print IO I couldn’t check if the bytes written equaled the bytes of data. I wasn’t sure if something was getting stuck on the server side.

    So, I changed the Content-Type of the response from application/json to text/html, so that I could query the page and just look at the actual response as text. Once I did that, I could see that the response was fine.

    I started to look for other causes, and I found that in the migration to the new server, I’d missed altering some URLs in the DB to point to the new server, which meant my application was trying to get some data from the old DB. This in turn was causing a load of timing issues, which was causing my problems. Once I fixed the config, the problems went away.