+-------------------------------+
| SERVER |
+----+ Request | +----------+ +-----------+ |
|User|--------------->| Target |-->| Perl | |
| | | | Embperl | | class | |
| |<---------------| script |<--| | |
+----+ Responce | +----------+ +-----------+ |
| |
+-------------------------------+
In this case, user'll see current page till then requested function returns results and new page will be generated. Because In Embperl 2 there is no way to flush buffers before everything is done - this is answer of Gerald Richter (man who develops Embperl).
So, I'd just want to display for the user some helpful message.
+-------------------------------+
| SERVER |
+----+ Request | +----------+ |
| |--------------->| Wait | |
|USER| | | page | |
| |<---------------| | |
+----+ Responce | +----+-----+ |
^ (wait) | | Redirect |
| | v |
| | +----------+ +---------+ |
| | | Target |--->| Perl | |
+------------------| script |<---| class | |
Respoce | | | | | |
(result) | +----------+ +---------+ |
+-------------------------------+
In this case, user calls wait page which display some message (and user can see it immediately because it's short request). Then wait page parses passed arguments, builds new request (target script name should be passed as argument) and does redirect to target script.
So, the user watches wait page message till then long running operation will be finished and result page will be generated.
| [reply] |
You didn't mention that you were using Embperl 2 before. Embperl can flush buffers, but Embperl 2 is a totally different system.
What's confusing about your diagram is what you mean by "redirect" in #2. If you are doing a standard HTTP redirect, the browser will simply load the other page immediately, not wait until it finishes. Maybe you are actually doing an internal fetch of some kind with LWP or an internal redirect?
The forking approach that merlyn described is a bit more complex, but better for scalability. The reason is that your approach will tie up an apache child process during the generation of the slow page, while the forking approach forks off the worker process and leaves the apache child free to handle more web requests.
| [reply] |
You didn't mention that you were using Embperl 2 before. Embperl can flush buffers, but Embperl 2 is a totally different system.
Sorry about that.
What's confusing about your diagram is what you mean by "redirect" in #2.
I mean simple redirect on Embperl script which call object method implemented long running operation. The browser will wait untill operation has finished because Embperl doesn't flush buffers till finish of page generation.
The forking approach that merlyn described is a bit more complex, but better for scalability.
I don't have pretensions to say that my approach is much better than merlyn's. ;))
I'd like to show your other way to do that. So in my case, this approach is better for me. I suspect that the best way to do wait message is implementing forking approach in the mod_perl handler. But I don't have enough knowledge of mod_perl and time to do that.
| [reply] |