Re: close connection for request, but continue

Hi Perrin,

>> I'm trying to achieve the following: when there is an incoming request, I
>> want to set a time limit in which an answer should be delivered to the
>> client, no matter what.
>>
>> However, since the work triggered by the initial request (there is another
>> request to other site involved)  might take much longer than that time
>> limit, I want that work to properly finish, despite the fact that the
>> initial request was 'served' already.
>
>
> TMTOWTDI, but the common way to do this is to add the long-running job to a
> job queue, and then redirect the user to a page that periodically checks if
> the job is done by using JavaScript requests.

It's not such a typical long-running job that I'm doing. It rather goes 
like this: whereas I most of the time can answer with what I have within 
the acceptable answer time, I sometimes have to make another request in 
the background. That too most of the time is served within acceptable 
time; _sometimes_ it isn't, so only occasionally it takes more.

The clue: let's say the backend service is pay-per-use, so I definitely 
don't want to throw away a started request. If I have launched a request 
in the back, I'd want to get the results, even if the initial requester 
was turned down in the meantime.

> If you don't have a job queue and don't want to add one just for this, you
> could use a cleanup handler to run the slow stuff after disconnecting:
> http://perl.apache.org/docs/2.0/user/handlers/http.html#PerlCleanupHandler

I'm afraid that won't fit, actually. It's not a typical Cleanup I'm after 
- I actually want to not abandon the request I've started, just for 
closing the incoming original request. The cleanup handler could relaunch 
the slow back request - but doing so I'd pay twice for it.

> That will tie up a mod_perl process though, so it's not a good way to go
> for large sites.

I'm aware of that, but that's less of a concern for now.

Many thanks,

Iosif Fettich