jswalker has asked for the wisdom of the Perl Monks concerning the following question:

Is there some requirement above and beyond the 'return DECLINED' from a PerlTransHandler to allow a thread to terminate normally?

Background: We use a commercial product to produce some of our web content. It has a large number of control parameters that are necessary to its function but of little use to the average user. To make links to our content more manageable we created a perl script to run as a cgi that accepts a minimum of data from the user, combines that with it's own catalog of information and generates the required 400-500 character URL required to produce the desired result. It all works great, except that the cgi basically has to send the result as a redirect, which generates yet another transaction to the server.

We thought, "Wouldn't it be great if we could just do the translation on the fly and save the back an forth?". So we added mod_perl to the system and rewrote the URL script as a PerlTransHandler.

In local testing everything seems to work just fine. We put it out in the world and after just a little bit, the server is sitting idle and Apache has quit responding altogether.

[Sun May 13 20:04:46 2012] [warn] Server ran out of threads to serve r +equests. Consider raising the ThreadsPerChild setting [Sun May 13 20:07:44 2012] [warn] (OS 64)The specified network name is + no longer available. : winnt_accept: Asynchronous AcceptEx failed. [Sun May 13 20:14:39 2012] [warn] (OS 64)The specified network name is + no longer available. : winnt_accept: Asynchronous AcceptEx failed. [Sun May 13 20:14:54 2012] [warn] (OS 64)The specified network name is + no longer available. : winnt_accept: Asynchronous AcceptEx failed.
Our environment is:
Server Version: Apache/2.2.22 (Win32) mod_perl/2.0.4-dev Perl/v5.10.0 Server Built: Jan 28 2012 11:16:39
We desperately need to do some additional things to protect our server from a lot of spurious traffic, thus our interest in mod_perl, but if we can't get a simple transhandler working it doesn't bode well for other additions to our Apache configuration. If anyone can offer a suggestion as to why the threads under mod_perl are not releasing, it would be greatly appreciated.

Replies are listed 'Best First'.
Re: Web Service using mod_perl with PerlTransHandler running out of threads
by Anonymous Monk on May 14, 2012 at 19:45 UTC
      Yes, I have been to those places too, and many others as well. The key components of my transhandler come straight out of "http://perl.apache.org/docs/2.0/user/handlers/http.html#PerlTransHandler", yet the fact remains that when I enable the mod_perl transhandler, the Apache server, after functioning normally for a while, soon becomes unresponsive. The report that it is out of threads is the only clue I have at present. If my transhandler itself adheres to the available documentation but the system is consuming threads, it seemed logical to presume that some additional step might be required to induce mod_perl/Apache to process a request fully to completion (i.e. release the responsible thread).
Re: Web Service using mod_perl with PerlTransHandler running out of threads
by Anonymous Monk on May 15, 2012 at 17:12 UTC
    Our environment is:

    Server Version: Apache/2.2.22 (Win32) mod_perl/2.0.4-dev Perl/v5.10.0 Server Built: Jan 28 2012 11:16:39 You are using a threaded version of Apache on Windows server? No wonder?

    Use Linux. Problem solved. CASE CLOSED!

    (courtesy of the Coalition to Stop Idiots from Using Bad Tools)

      You are using a threaded version of Apache on Windows server? No wonder?

      Amazing isn't it, esp since apache.org provides them, because they actually work on windows, because windows has better threads than linux

        Gee, and for all these years I thought the threaded model was a workaround for systems that didn't have fork.

        Since the mix of Apache and Windows and mod_perl seems to have sparked some discussion - Is there some disconnect in these implementations (even though all of them are builds intended for the Win32 environment)? Some inherent instability? I'm game to fight this fight but not if it is a lost cause from the start.

        While we are on the topic is there anything suitable to this environment that would give me the sort of visibility of Apache processing that 'procmon' from the Windows sysinternals package provides for that environment? I am inclined to think I could resolve this if I had some way of seeing what is going on in there as Apache winds down to flatline. VMonitor is not an option. Apache::DB seems too 'down in the weeds' given that this is not a hard stop but a slow death. I am thinking I need to see the dynamics of what is going on with the various Apache threads but I haven't a clue yet on how to get that.

      I use what I use because I must. I've posted this to try to get some help from those more knowledgeable than myself in figuring out what is going on with what I have. If you just want someone to flame why not start with the Man in the Mirror.