At 08:18 PM 11/18/2002 -0700, Rob Nagler wrote:
....
>We digress.  The problem is to build a UI to Sabre.  I still haven't
>seen any numbers which demonstrate the simple solution doesn't work.
>Connecting to Sabre is no different than connecting to an e-commerce
>gateway.  Both can be done by connecting directly from the Apache
>child to the remote service and returning a result.

Hi,

My question with this approach is not whether it works for synchronous
execution (the user is willing to wait for the results to come back)
but whether it makes sense for asynchronous execution (the user will
come back and get the results later).

In fact, we provide our users with the option:

   1. fetch the data now and display it, OR
   2. put the request in a queue to be fetched and then later displayed

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.

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).
Why not let there be web server processes and queue worker processes
and they each do their own job?  Web servers seem to me to be for
synchronous activity, where the user is waiting for the results.

Stephen

P.S. Another limitation of the "use Apache servers for all server processing"
philosophy seems to be scheduled events or system events (those not
initiated by an HTTP request, which are user events).

example: Our system allows users to set up a schedule of requests to be run.
i.e. "Every Tuesday at 3:00am, put this request into the queue".
This is a scheduled event rather than a user event.
How is a web server process going to wake up and begin processing this?
(unless of course everyone who puts something into the queue must send
a dummy HTTP request to wake up the web servers)



Reply via email to