At 01:42 PM 4/26/2002 -0400, Perrin Harkins wrote:
>Stephen Adkins wrote:
>> Yes, I like Apache/mod_perl for everything that can be satisfied
>> within a short period of time (i.e. synchronous calls).
>> However, when I initiate tasks from a browser which take a long time,
>> I think the work needs to be offloaded to another server... one that
>> can stick around and do the work.
>
>I don't see how another server is more able to "stick around" than
>mod_perl. You can simply send back a "message received" indication, cut
>the connection to the client, and do the work.
I was thinking along the lines of:
* mod_perl processes are resource intensive
* we want to get done with the Apache child process as soon as
possible so that it can go back to servicing requests
* don't use them for tasks such as waiting on synchronous
network API's
However, your suggestion is understood.
It is in keeping with Rob Nagler's comments.
>> Furthermore,
>> requests need to be queued. This is not a good use for a web server.
>> Thus the need for another server.
>
>A system for processing queues is very different from an RPC server.
>Any of these servers (including mod_perl) would be good for putting
>requests in the queue, but for processing the queue you would want
>something different, like a simple forked daemon that has no RPC component.
You are quite right.
Your suggestion helped clarify my thinking on this point.
I am guessing that Net::Daemon would be a good package to build on.
(...which is in fact what PlRPC uses.)
I was thinking that the RPC call might be a good way to put the task
in the queue and retrieve the results, but that seems unnecessary now.
Stephen
P.S.
