Stephen Adkins wrote: > At 10:27 AM 4/26/02 -0600, Rob Nagler wrote: > >>Stephen Adkins writes: >> >>>There are going to be an increasing number of cases where >>>the P5EE needs a core server, separate from the web server. >>>(Similar in some respects to how an EJB server is separate >>>from the web server in which Servlets run.) >>> >>I think the reliability/flexibility/security of Apache/mod_perl is >>hard to beat. We initially had separate servers in bOP, and we >>through them out in favor of using Apache for all RPC. We marshall >>requests to mulitpart/form-data, so we get maximum reuse. However, >>you might consider SOAP if you want more complexity. >> > > Hi, > > 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. > > Our example: We have developed a competitive rate shopping tool > for the rental car industry. This is not a site for consumers but > for members of the industry who are seeking to set their rates > wisely with respect to their competitors. > > We have a private WAN connection to Sabre (the travel reservation system) > and some Sabre interface libraries. We have written the XS interface > so that we can use these Sabre libraries from Perl. > > To request the rates for all car rental companies for a single day > for a single car type is a transaction with Sabre that takes about > 3 seconds. A report requiring data for the next 30 days for 5 car > types would take 7.5 minutes. This is too long for the user to > wait (and the browser would most likely time out). Furthermore, > requests need to be queued. This is not a good use for a web server. > Thus the need for another server. > > So on my original question, I am coming to the following conclusion. > > * POE is good if you want to field multiple requests within the same > process. Thus, there can be a lot of interaction between requests > because they share all of the same data. POE Sessions can keep > logically distinct activities from interfering with each other, > but they still all run in the same process. POE will not help you > take advantage of multiple SMP CPU's (until threading becomes more > mainstream), nor will it help if my "handler" needs to make calls to > a library which blocks (my Sabre library) and that doesn't have a > non-blocking interface. Of course, I could always fork a child > process to stick around and do the work (sorry win32 users). > > * PlRPC is good if you want a separate process to handle each RPC > call. This is not good for interaction with other requests, but > that is not necessary in my case. I am still looking into whether > I can return an RPC result (the request_id) from the RPC subprocess > and then remain alive in order to do the work. As above, I could > always fork a child. > > Stephen >
Well I seem to be missing something. Are you removing the need for the process to take 7.5 minutes? If not then how are either of the above processes going to assist. In this case it seems you are at the mercy of the Sabre engine. Here again I would use mod_perl and exec a process to query for the results and have those results stored into an appropriate container and inform the user that the results will be avalable later, you could have the system email them the results if that is acceptable. Aaron Johnson
