Iosif:
You will need:
[] a background state storage location (database table with unique row ID;
directory with unique ID which points to the state file).
[] Your user-facing request page accepts the request, scheduled the work,
responds with a page which auto-refreshes against the GUID which
On 21.04.2016 11:20, Iosif Fettich wrote:
Dear mod_perl list,
please consider my gratefulness for any hints/insight :)
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.
A job queue is also better because it stops un-controlled forking or
excessive numbers of "dead" web connections hanging around. It will just
queue requests until resources are available.. You may find handling
multiple of these jobs in parallel eats up all your processor/memory
resources..
On Thu, Apr 21, 2016 at 9:48 AM, Iosif Fettich wrote:
> 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
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
On Thu, Apr 21, 2016 at 5:20 AM, Iosif Fettich wrote:
>
> 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
Dear mod_perl list,
please consider my gratefulness for any hints/insight :)
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