Hi all,

On Tuesday, November 19, 2002, at 11:09 PM, Perrin Harkins wrote:

Stephen Adkins wrote:

So what I think you are saying for option 2 is:

* Apache children (web server processes with mod_perl) have two
personalities:
- user request processors
- back-end work processors
* When a user submits work to the queue, the child is acting in a
"user request" role and it returns the response quickly.
* After detaching from the user, however, it checks to see if fewer
than four children are processing the queue and if so, it logs into
the mainframe and starts processing the queue.
* When it finishes the request, it continues to work the queue until
no more work is available, at which time, it quits its "back-end
processor" personality and returns to wait for another HTTP request.

This just seems a bit odd (and unnecessarily complex).

It does when you put it like that, but it doesn't have to be that way.
I've implemented the exact thing Perrin describes in our SMS game platform (read a bit about it here: http://perl.apache.org/outstanding/success_stories/sms_server.html).

When synchronous requests come in that trigger some event that has to take place in the future *and* that runs in the same Apache server instance, I have an external (simple) daemon that reads timer events from a shared database table and posts HTTP requests to the Apache server instance.

The reason I did it like this is that I can easily (not to mention quickly) run perl code in Apache *and* it is quite a stable server, much more stable than something I could whip out in perl. I did try some perl preforking server code (from Lincoln D. Stein's book and Net::Server::PreFork as well as some self-programmed stuff) but none of them seemed to be stable/fast under heavy load even though I would have preferred that as it would allow me to do something to handle data-sharing between children via the parent which always seems to be in issue in Apache/mod_perl.

The only thing that now and then is problematic is that Apache child processes in which my perl code runs are not easily coordinated (at least I still haven't found a good way). So this situation (from Stephen's mail):

We have a fixed number of mainframe login id's, so we can only run a
limited number (say 4) of them at a time.
still is something I haven't figured out. Basically, I need some way to coordinate the children so each child can find out what the other children are doing.

BTW: I've been reading up a lot on J2EE lately and it appears more and more that a J2EE app server could quite nicely provide for my needs (despite all shortcomings and issues of course). Now if there only was a P5EE app server ;)

Regards,

Bas.


Reply via email to