For me, one of things I am grappling with is how to create some of scheduling daemon within the mod_perl environment. I mean, I like mod_perl (and Apache2), but there are times when I need to run a script that takes a really long time to process. In Apache it will time out.
I hear that in the servlet environment, you can create a java daemon of sorts, that the web application can poll continuously to see if the job is completed, otherwise return a page that will reload itself 5 minutes later. I like that kind of mixture, and I wonder if the same can be done in the mod_perl enviromment.
People do that, but I've never understood why. It seems to me that there is a much better solution but I've never heard of it being used so possibly there's something wrong that no one's been able to explain to me.
The problem is, you have two components, A and B. A can initiate communication to B but B cannot initiate communication to A. However, B needs to communicate asynchronous data to A. In your case, A is a browser and B is a server and the data is the completion of a long running task. The solution you mention above is to have A poll B to see if the task is done. This requires a tradeoff between efficiency and latency, tuned by the selection of the polling frequency.
Instead, it seems to me it should be possible to have A simply keep a pending connection open to B, which is "completed" when B has the data. In this case, the browser would request a page but the page request wouldn't complete until B was ready or a timeout period had elapsed, at which point the existing request is complete as "failed" and a new one created. This means that A polls slowly, at (roughly) the Apache time out interval, but B can still deliver an update in near real time. The only technological challenge is finding an inter-process/inter-thread mechanism that can block with a timeout. "select" is one choice for this mechanism. The browser request does a select on status output from the background process with a timeout. If the background process finishes, the select terminates and the result is returned. If the select timesout, a "reload this page immediately" result is returned. The timeout should be somewhat shorter than the Apache timeout. You also need to be a little clever to detect the case where the background process finishes during the timeout processing but that's not too hard.
Now, the price you pay here is the cost of having a TCP/IP connection open basically all the time between the browser and the server which is not always acceptable (if one has a very large number of clients expected to be waiting simultaneously).
I haven't tried this for a browser / server implementation. I worked it out originally to let a kernel driver make asynchronous requests to application space processes. I've also used it to deal with processes using a synchronous RPC but separated by dynamic NAT. Is there some reason it wouldn't work for a browser/server as well? I suggested it multiple times at the large tech company I used to work for but I never got any feedback except that it was treated as a brand new, interesting idea every time I brought it up. I thought this technique was well known but perhaps not - time for a patent :-)?
_______________________________________________ ActivePerl mailing list [email protected] To unsubscribe: http://listserv.ActiveState.com/mailman/mysubs
