Mailing-List: contact modperl-help@perl.apache.org; run by ezmlm
Precedence: bulk
From: "Frotz Fa'Atuai (ffaatuai)" <ffaatuai@cisco.com>
To: =?iso-8859-1?Q?Andr=E9_Warnier_=28tomcat=29?= <aw@ice-sa.com>,
        "modperl@perl.apache.org" <modperl@perl.apache.org>
Subject: Re: close connection for request, but continue
Thread-Topic: close connection for request, but continue
Thread-Index: AQHRm9tPNtx6Y9zs/km5G6j+8v+hj5+UYhAA
Date: Thu, 21 Apr 2016 14:54:08 +0000
Message-ID: <D33E3497.E057B%ffaatuai@cisco.com>
References: <alpine.LRH.2.20.1604211134010.30783@pony.netsoft.ro>
 <5718E58B.3030203@ice-sa.com>
In-Reply-To: <5718E58B.3030203@ice-sa.com>
Accept-Language: en-US
Content-Language: en-US
user-agent: Microsoft-MacOutlook/14.5.6.150930
x-ms-exchange-messagesentrepresentingtype: 1
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: [10.19.133.108]
Content-Type: text/plain; charset="iso-8859-1"
Content-ID: <02B93FD6926A7B4A817C7D752011A692@emea.cisco.com>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0

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 reports
status of the background request.
[] Your user-facing status page auto-refreshes to itself while the job is
in motion.
[] Your user-facing status page auto-refreshes to a "you're done; your
results are here / have been mailed to you".

Observations:
[] My corporate business users can follow along with a 15 second
auto-refresh (as long as the page clearly indicates an auto-refresh in 15
seconds).  Count-down timers are probably better.
[] My technical users close the pop-up tab after the first request (not
caring for the intermediate status pages and knowing that the result has
been accomplished or mailed to them).

Asides:
[] Some of our backend jobs take a long time (lots of data to grind
through); these tend towards email status.
[] The database-based queue view (assuming you're internally facing only)
allows your support teams to observed queued jobs (things which will
happen in the future), active jobs (things running right now on some
machine), completed jobs (jobs which succeeded), failed jobs (jobs which
did not succeed).

Hopefully these implementation specifics and operational observations
assist you as you take Andr=E9's excellent summary and put it all to work.
--
Frotz
EMAN
Cisco Systems, Inc.

On 2016/04/21, 07:36, "Andr=E9 Warnier (tomcat)" <aw@ice-sa.com> wrote:

>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.
>>
>> 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.
>>
>
>The "canonical" way to do this, would be something like
>- the client sends the request to the server
>- the server allocates a process (or thread or whatever) to process this
>request
>- this request-processing process "delegates" this browser request to
>some other,=20
>independent-of-the-webserver process, which can take as long as necessary
>to fulfill the=20
>(background part of) the request
>- the request-processing process does not wait for the response or the
>exit of that=20
>independent process, but returns a response right away to the client
>browser (such as=20
>"Thank you for your request. It is being handled by our back-office. You
>will receive an=20
>email when it's done.".)
>- and then, as far as the webserver is concerned, this client request is
>finished=20
>(cleanly), and the request-processing process can be re-allocated to some
>other incoming=20
>request
>
>Optionally, you could provide a way for the client to periodically
>enquire as to the=20
>advancement status of his request.