-When I run a PHP script with a infinite loop, the apache process(using
mod_prefork) still busy (php.ini timeouts disabled) 'forever' (the obvious
fact).
-When I run again the same script with the same URL, apache seems to
'enqueue' the second request, because no other process seems to be running.
-But if I send a SIGTERM to the apache process, it seems to begin processing
the second script, and stop the first.
-If I run the script using a different URL(just by changing the query
string), it seems to run both process parallely.
It's just the first step. I've done the same tests, but using mod_rewrite.
It's different: even with different URL, the process get 'queued'.
I just ask: is this the expected behaviour??
It's causing a little throuble for me. When a PHP script generates a bigger
report(taking about ten minutes or more), the user seems to be impatient.
They're doing refreshs on the page. So, for each refresh apache is queuing a
new script, and just begin running this when the queue is empty again.
-When I run a=
PHP script with a infinite loop, the apache process(using mod_prefork) sti=
ll busy (php.ini timeouts disabled) 'forever' (the obvious fact).
r>
-When I run again the same script with the same URL, apache seems to 'e=
nqueue' the second request, because no other process seems to be runnin=
g. -But if I send a SIGTERM to the apache process, it seems to begin pro=
cessing the second script, and stop the first.
-If I run the script using a different URL(just by changing the query strin=
g), it seems to run both process parallely.
It's just the first =
step. I've done the same tests, but using mod_rewrite. It's differe=
nt: even with different URL, the process get 'queued'.
I just ask: is this the expected behaviour??
It's causing a =
little throuble for me. When a PHP script generates a bigger report(taking =
about ten minutes or more), the user seems to be impatient. They're doi=
ng refreshs on the page. So, for each refresh apache is queuing a new scrip=
t, and just begin running this when the queue is empty again.
color: rgb(255, 255, 255);" title=3D"o que voc=EAs me sugerem?">What do you=
suggest me?
Thank you, Bruno Moreira Guedes
--0016e6dab03490bb0004819a610e--
Re: mod_php script "queue"
am 12.03.2010 17:31:54 von Nilesh Govindrajan
On Fri, Mar 12, 2010 at 6:49 PM, Bruno - e-comBR wrote:
> Hello,
>
> While performing some tests, I saw that:
>
> -When I run a PHP script with a infinite loop, the apache process(using
> mod_prefork) still busy (php.ini timeouts disabled) 'forever' (the obvious
> fact).
> -When I run again the same script with the same URL, apache seems to
> 'enqueue' the second request, because no other process seems to be running.
> -But if I send a SIGTERM to the apache process, it seems to begin processing
> the second script, and stop the first.
> -If I run the script using a different URL(just by changing the query
> string), it seems to run both process parallely.
>
> It's just the first step. I've done the same tests, but using mod_rewrite.
> It's different: even with different URL, the process get 'queued'.
>
> I just ask: is this the expected behaviour??
>
> It's causing a little throuble for me. When a PHP script generates a bigger
> report(taking about ten minutes or more), the user seems to be impatient.
> They're doing refreshs on the page. So, for each refresh apache is queuing a
> new script, and just begin running this when the queue is empty again.
>
> What do you suggest me?
>
> Thank you,
> Bruno Moreira Guedes
>
I don't use mod_php, so don't know about its behavior. But I recommend
you inform the users that the report can take upto ten minutes to
generate and to be patient. That's the only solution I see.
--
Nilesh Govindarajan
Site & Server Administrator
www.itech7.com
------------------------------------------------------------ ---------
The official User-To-User support forum of the Apache HTTP Server Project.
See for more info.
To unsubscribe, e-mail: users-unsubscribe@httpd.apache.org
" from the digest: users-digest-unsubscribe@httpd.apache.org
For additional commands, e-mail: users-help@httpd.apache.org
Re: mod_php script "queue"
am 12.03.2010 18:36:18 von Reese
On 12-Mar-10 11:31, Nilesh Govindarajan wrote:
> On Fri, Mar 12, 2010 at 6:49 PM, Bruno - e-comBR wrote:
>> It's causing a little throuble for me. When a PHP script generates a bigger
>> report(taking about ten minutes or more), the user seems to be impatient.
>> They're doing refreshs on the page. So, for each refresh apache is queuing a
>> new script, and just begin running this when the queue is empty again.
>>
>> What do you suggest me?
>>
>> Thank you,
>> Bruno Moreira Guedes
>>
>
> I don't use mod_php, so don't know about its behavior. But I recommend
> you inform the users that the report can take upto ten minutes to
> generate and to be patient. That's the only solution I see.
Else, if you can make the PHP script 'smart' in some way so that a
popup or other visual indicator will give constant, visual feedback
on the progress of the request. With a "Cancel" button that functions
to kill the original request while blocking page refreshes. They can
start over from scratch if they like.
Reese
------------------------------------------------------------ ---------
The official User-To-User support forum of the Apache HTTP Server Project.
See for more info.
To unsubscribe, e-mail: users-unsubscribe@httpd.apache.org
" from the digest: users-digest-unsubscribe@httpd.apache.org
For additional commands, e-mail: users-help@httpd.apache.org
Re: mod_php script "queue"
am 12.03.2010 18:50:51 von Nilesh Govindrajan
On Fri, Mar 12, 2010 at 11:06 PM, Reese wrote:
> On 12-Mar-10 11:31, Nilesh Govindarajan wrote:
>>
>> On Fri, Mar 12, 2010 at 6:49 PM, Bruno - e-comBR
>> wrote:
>
>>> It's causing a little throuble for me. When a PHP script generates a
>>> bigger
>>> report(taking about ten minutes or more), the user seems to be impatien=
t.
>>> They're doing refreshs on the page. So, for each refresh apache is
>>> queuing a
>>> new script, and just begin running this when the queue is empty again.
>>>
>>> What do you suggest me?
>>>
>>> Thank you,
>>> Bruno Moreira Guedes
>>>
>>
>> I don't use mod_php, so don't know about its behavior. But I recommend
>> you inform the users that the report can take upto ten minutes to
>> generate and to be patient. That's the only solution I see.
>
> Else, if you can make the PHP script 'smart' in some way so that a
> popup or other visual indicator will give constant, visual feedback
> on the progress of the request. With a "Cancel" button that functions
> to kill the original request while blocking page refreshes. They can
> start over from scratch if they like.
>
> Reese
>
>
>
> ------------------------------------------------------------ ---------
> The official User-To-User support forum of the Apache HTTP Server Project=
..
> See for more info.
> To unsubscribe, e-mail: users-unsubscribe@httpd.apache.org
> =A0" =A0 from the digest: users-digest-unsubscribe@httpd.apache.org
> For additional commands, e-mail: users-help@httpd.apache.org
>
>
I think that's possible with AJAX-JSON combination.
But the cronjob solution will be best if he doesn't know PHP (an
administrator's job is not to tweak the web-interface!)
--=20
Nilesh Govindarajan
Site & Server Administrator
www.itech7.com
------------------------------------------------------------ ---------
The official User-To-User support forum of the Apache HTTP Server Project.
See for more info.
To unsubscribe, e-mail: users-unsubscribe@httpd.apache.org
" from the digest: users-digest-unsubscribe@httpd.apache.org
For additional commands, e-mail: users-help@httpd.apache.org
> On 12-Mar-10 11:31, Nilesh Govindarajan wrote:
>
>> On Fri, Mar 12, 2010 at 6:49 PM, Bruno - e-comBR
>> wrote:
>>
>
> It's causing a little throuble for me. When a PHP script generates a
>>> bigger
>>> report(taking about ten minutes or more), the user seems to be impatient.
>>> They're doing refreshs on the page. So, for each refresh apache is
>>> queuing a
>>> new script, and just begin running this when the queue is empty again.
>>>
>>> What do you suggest me?
>>>
>>> Thank you,
>>> Bruno Moreira Guedes
>>>
>>>
>> I don't use mod_php, so don't know about its behavior. But I recommend
>> you inform the users that the report can take upto ten minutes to
>> generate and to be patient. That's the only solution I see.
>>
>
> Else, if you can make the PHP script 'smart' in some way so that a
> popup or other visual indicator will give constant, visual feedback
> on the progress of the request. With a "Cancel" button that functions
> to kill the original request while blocking page refreshes. They can
> start over from scratch if they like.
>
> Reese
>
>
>
>
> ------------------------------------------------------------ ---------
> The official User-To-User support forum of the Apache HTTP Server Project.
> See for more info.
> To unsubscribe, e-mail: users-unsubscribe@httpd.apache.org
> " from the digest: users-digest-unsubscribe@httpd.apache.org
> For additional commands, e-mail: users-help@httpd.apache.org
>
>
Is there any way to cache the report?
Maybe for that specific page (or the reports pages in general) you should
institute a process whereby the webpage doesn't run the report itself but
acts an an interface to a CLI task that generates the report. When you hit
the webpage, it attempts to obtain a "report lock", at which point the
report begins to run, once the report is generated the lock can be released,
and the web page can retrieve and report the results. The lock can be
implemented any number of ways, I've done it in the past by simply touching
and then deleting a file in the /tmp folder.
To eventually ensure the user sees the report when it's done being
generated, you could do some fancy Keep-alive with the http request, or just
have some javascript on the page that automatically reloads it, and upon
reload the script will check to see if there's a report built for that user,
otherwise it checks to see if there's a lock. If there's a lock, it stops
and waits to try again soon. If there is no lock, it starts a new report.
Just some thoughts! Good luck with your problem, I don't think it's really
an apache problem.
It's causing a little throuble for me. When a PHP script generates a bi=
gger
report(taking about ten minutes or more), the user seems to be impatient.
r>
They're doing refreshs on the page. So, for each refresh apache is queu=
ing a
new script, and just begin running this when the queue is empty again.
What do you suggest me?
Thank you,
Bruno Moreira Guedes
I don't use mod_php, so don't know about its behavior. But I recomm=
end
you inform the users that the report can take upto ten minutes to
generate and to be patient. That's the only solution I see.
Else, if you can make the PHP script 'smart' in some way so that a<=
br>
popup or other visual indicator will give constant, visual feedback
on the progress of the request. With a "Cancel" button that funct=
ions
to kill the original request while blocking page refreshes. They can
The official User-To-User support forum of the Apache HTTP Server Project.<=
br>
See <URL:
lank">http://httpd.apache.org/userslist.html> for more info.
To unsubscribe, e-mail:
g" target=3D"_blank">users-unsubscribe@httpd.apache.org
 "  from the digest:
cribe@httpd.apache.org" target=3D"_blank">users-digest-unsubscribe@httpd.ap=
ache.org
For additional commands, e-mail:
org" target=3D"_blank">users-help@httpd.apache.org
Is there any way to cache the repor=
t?
Maybe for that specific page (or the reports pa=
ges in general) you should institute a process whereby the webpage doesn=
9;t run the report itself but acts an an interface to a CLI task that gener=
ates the report. Â When you hit the webpage, it attempts to obtain a &q=
uot;report lock", at which point the report begins to run, once the re=
port is generated the lock can be released, and the web page can retrieve a=
nd report the results. Â The lock can be implemented any number of ways=
, I've done it in the past by simply touching and then deleting a file =
in the /tmp folder.
To eventually ensure the user sees the report when it=
39;s done being generated, you could do some fancy Keep-alive with the http=
request, or just have some javascript on the page that automatically reloa=
ds it, and upon reload the script will check to see if there's a report=
built for that user, otherwise it checks to see if there's a lock. =C2=
=A0If there's a lock, it stops and waits to try again soon. Â If th=
ere is no lock, it starts a new report.
Just some thoughts! Good luck with your problem, I don&=
#39;t think it's really an apache problem.
--00504502983643964204819eff4d--
Re: mod_php script "queue"
am 12.03.2010 19:59:46 von Reese
On 12-Mar-10 13:49, Jonathan Zuckerman wrote:
> On Fri, Mar 12, 2010 at 9:36 AM, Reese wrote:
>
>> On 12-Mar-10 11:31, Nilesh Govindarajan wrote:
>>
>>> On Fri, Mar 12, 2010 at 6:49 PM, Bruno - e-comBR
>>> wrote:
>>>
>> It's causing a little throuble for me. When a PHP script generates a
>>>> bigger
>>>> report(taking about ten minutes or more), the user seems to be impatient.
>>>> They're doing refreshs on the page. So, for each refresh apache is
>>>> queuing a
>>>> new script, and just begin running this when the queue is empty again.
>>>>
>>>> What do you suggest me?
>>>>
>>>> Thank you,
>>>> Bruno Moreira Guedes
>>>>
>>>>
>>> I don't use mod_php, so don't know about its behavior. But I recommend
>>> you inform the users that the report can take upto ten minutes to
>>> generate and to be patient. That's the only solution I see.
>>>
>> Else, if you can make the PHP script 'smart' in some way so that a
>> popup or other visual indicator will give constant, visual feedback
>> on the progress of the request. With a "Cancel" button that functions
>> to kill the original request while blocking page refreshes. They can
>> start over from scratch if they like.
>>
>> Reese
>>
>>
>>
>>
>> ------------------------------------------------------------ ---------
>> The official User-To-User support forum of the Apache HTTP Server Project.
>> See for more info.
>> To unsubscribe, e-mail: users-unsubscribe@httpd.apache.org
>> " from the digest: users-digest-unsubscribe@httpd.apache.org
>> For additional commands, e-mail: users-help@httpd.apache.org
>>
>>
> Is there any way to cache the report?
You could get the parameters sorted out, then create a cron job
from it and feed it to a .log file. This log file could be made
available to administrators only, the world or something in
between, depending on where in the file system it is located and
the associated permissions.
> To eventually ensure the user sees the report when it's done being
> generated, you could do some fancy Keep-alive with the http request, or just
> have some javascript on the page that automatically reloads it, and upon
> reload the script will check to see if there's a report built for that user,
> otherwise it checks to see if there's a lock. If there's a lock, it stops
> and waits to try again soon. If there is no lock, it starts a new report.
Or compress and store or mail it to them (and others?), starting a new
log file after each clock cycle.
This is starting to feel like reinventing HTTP access logs. We got off
track somewhere.
Reese
------------------------------------------------------------ ---------
The official User-To-User support forum of the Apache HTTP Server Project.
See for more info.
To unsubscribe, e-mail: users-unsubscribe@httpd.apache.org
" from the digest: users-digest-unsubscribe@httpd.apache.org
For additional commands, e-mail: users-help@httpd.apache.org
> On 12-Mar-10 13:49, Jonathan Zuckerman wrote:
>
>> On Fri, Mar 12, 2010 at 9:36 AM, Reese wrote:
>>
>> On 12-Mar-10 11:31, Nilesh Govindarajan wrote:
>>>
>>> On Fri, Mar 12, 2010 at 6:49 PM, Bruno - e-comBR
>>>> wrote:
>>>>
>>>> It's causing a little throuble for me. When a PHP script generates a
>>>
>>>> bigger
>>>>> report(taking about ten minutes or more), the user seems to be
>>>>> impatient.
>>>>> They're doing refreshs on the page. So, for each refresh apache is
>>>>> queuing a
>>>>> new script, and just begin running this when the queue is empty again.
>>>>>
>>>>> What do you suggest me?
>>>>>
>>>>> Thank you,
>>>>> Bruno Moreira Guedes
>>>>>
>>>>>
>>>>> I don't use mod_php, so don't know about its behavior. But I recommend
>>>> you inform the users that the report can take upto ten minutes to
>>>> generate and to be patient. That's the only solution I see.
>>>>
>>>> Else, if you can make the PHP script 'smart' in some way so that a
>>> popup or other visual indicator will give constant, visual feedback
>>> on the progress of the request. With a "Cancel" button that functions
>>> to kill the original request while blocking page refreshes. They can
>>> start over from scratch if they like.
>>>
>>> Reese
>>>
>>>
>>>
>>>
>>> ------------------------------------------------------------ ---------
>>> The official User-To-User support forum of the Apache HTTP Server
>>> Project.
>>> See for more info.
>>> To unsubscribe, e-mail: users-unsubscribe@httpd.apache.org
>>> " from the digest: users-digest-unsubscribe@httpd.apache.org
>>> For additional commands, e-mail: users-help@httpd.apache.org
>>>
>>>
>>> Is there any way to cache the report?
>>
>
> You could get the parameters sorted out, then create a cron job
> from it and feed it to a .log file. This log file could be made
> available to administrators only, the world or something in
> between, depending on where in the file system it is located and
> the associated permissions.
>
>
> To eventually ensure the user sees the report when it's done being
>> generated, you could do some fancy Keep-alive with the http request, or
>> just
>> have some javascript on the page that automatically reloads it, and upon
>> reload the script will check to see if there's a report built for that
>> user,
>> otherwise it checks to see if there's a lock. If there's a lock, it stops
>> and waits to try again soon. If there is no lock, it starts a new report.
>>
>
> Or compress and store or mail it to them (and others?), starting a new
> log file after each clock cycle.
>
> This is starting to feel like reinventing HTTP access logs. We got off
> track somewhere.
>
>
> Reese
>
>
>
> ------------------------------------------------------------ ---------
> The official User-To-User support forum of the Apache HTTP Server Project.
> See for more info.
> To unsubscribe, e-mail: users-unsubscribe@httpd.apache.org
> " from the digest: users-digest-unsubscribe@httpd.apache.org
> For additional commands, e-mail: users-help@httpd.apache.org
>
>
I would like to thank everyone by this ideas. I'll test each one and see
what happen :-)
But if someone knows a way to adjust this behaviour(some 'undocumented
procedure'), please tell me.
The official User-To-User support forum of the Apache HTTP Server Project.<=
br>
See <URL:
lank">http://httpd.apache.org/userslist.html> for more info.
To unsubscribe, e-mail:
g" target=3D"_blank">users-unsubscribe@httpd.apache.org
=A0" =A0 from the digest:
ttpd.apache.org" target=3D"_blank">users-digest-unsubscribe@httpd.apache.or=
g
For additional commands, e-mail:
org" target=3D"_blank">users-help@httpd.apache.org
Is there any way to cache the report?
You could get the parameters sorted out, then create a cron job
from it and feed it to a .log file. This log file could be made
available to administrators only, the world or something in
between, depending on where in the file system it is located and
the associated permissions.
204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
To eventually ensure the user sees the report when it's done being
generated, you could do some fancy Keep-alive with the http request, or jus=
t
have some javascript on the page that automatically reloads it, and upon
>
reload the script will check to see if there's a report built for that =
user,
otherwise it checks to see if there's a lock. =A0If there's a lock,=
it stops
and waits to try again soon. =A0If there is no lock, it starts a new report=
..
Or compress and store or mail it to them (and others?), starting a new
log file after each clock cycle.
This is starting to feel like reinventing HTTP access logs. We got off
The official User-To-User support forum of the Apache HTTP Server Project.<=
br>
See <URL:
lank">http://httpd.apache.org/userslist.html> for more info.
To unsubscribe, e-mail:
g" target=3D"_blank">users-unsubscribe@httpd.apache.org
=A0" =A0 from the digest:
httpd.apache.org" target=3D"_blank">users-digest-unsubscribe@httpd.apache.o=
rg
For additional commands, e-mail:
org" target=3D"_blank">users-help@httpd.apache.org
=3D"">
gin: 2px 6px 0pt 0pt; float: left;">
-flash" data=3D"http://www.gstatic.com/translate/sound_player.swf" id=3D"tt=
s_object" width=3D"18" height=3D"18">
/translate/sound_player.swf" name=3D"movie">
anslate_tts%3Fq%3DI%2Bwould%2Blike%2Bto%2Bthank%2Beveryone%2 Bfor%2Bideas%26=
tl%3Den" name=3D"flashvars">
ram value=3D"always" name=3D"allowScriptAccess">
r: rgb(255, 255, 255);" title=3D"eu gostaria de agradecer a todos pelas id=
=E9ias" onmouseover=3D"this.style.backgroundColor=3D'#ebeff9'" onmo=
useout=3D"this.style.backgroundColor=3D'#fff'">I would like to than=
k everyone by this ideas. I'll test each one and see what happen :-)
>
But if someone knows a way to adjust this behaviour(some 'undocumented =
procedure'), please tell me.
Thanks, Bruno Moreira Guedes =
--0016e6d778ed6749700481eb367e--
Re: mod_php script "queue"
am 16.03.2010 15:00:58 von Roger
Do you have persistent connections on?
-r
------------------------------------------------------------ ---------
The official User-To-User support forum of the Apache HTTP Server Project.
See for more info.
To unsubscribe, e-mail: users-unsubscribe@httpd.apache.org
" from the digest: users-digest-unsubscribe@httpd.apache.org
For additional commands, e-mail: users-help@httpd.apache.org
> Do you have persistent connections on?
>
> -r
>
> ------------------------------------------------------------ ---------
> The official User-To-User support forum of the Apache HTTP Server Project.
> See for more info.
> To unsubscribe, e-mail: users-unsubscribe@httpd.apache.org
> " from the digest: users-digest-unsubscribe@httpd.apache.org
> For additional commands, e-mail: users-help@httpd.apache.org
>
>
Are you talking about keep alive?
If so, yes, we're using it.
2010/3/16 Roger <
f=3D"mailto:rnodal@gmail.com">rnodal@gmail.com>
e class=3D"gmail_quote" style=3D"border-left: 1px solid rgb(204, 204, 204);=
margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
Do you have persistent connections on?
The official User-To-User support forum of the Apache HTTP Server Project.<=
br>
See <URL:
lank">http://httpd.apache.org/userslist.html> for more info.
To unsubscribe, e-mail:
g">users-unsubscribe@httpd.apache.org
=A0 " =A0 from the digest:
@httpd.apache.org">users-digest-unsubscribe@httpd.apache.org
For additional commands, e-mail:
org">users-help@httpd.apache.org
Are you talking about keep alive? If =
so, yes, we're using it.
--0016e64c0632a47e670481ebb635--
Re: mod_php script "queue"
am 16.03.2010 15:33:25 von Roger
I may have miss-understood your question but the fact that your second
script gets put in a queue may have to do with the fact that you are
using persistent connections. Have you tried disabling this off to see
if apache process the second request right of way?
I'm not saying that disabling persistent connections is the solution
that you are having with your report page, I'm mostly referring to the
question of whether this was the expected behavior.
-r
------------------------------------------------------------ ---------
The official User-To-User support forum of the Apache HTTP Server Project.
See for more info.
To unsubscribe, e-mail: users-unsubscribe@httpd.apache.org
" from the digest: users-digest-unsubscribe@httpd.apache.org
For additional commands, e-mail: users-help@httpd.apache.org
Re: mod_php script "queue"
am 16.03.2010 15:35:08 von Roger
Sorry I meant to say:
"I'm not saying that disabling persistent connections is the solution
to the problem
that you are having with your report page"
-r
------------------------------------------------------------ ---------
The official User-To-User support forum of the Apache HTTP Server Project.
See for more info.
To unsubscribe, e-mail: users-unsubscribe@httpd.apache.org
" from the digest: users-digest-unsubscribe@httpd.apache.org
For additional commands, e-mail: users-help@httpd.apache.org
Re: mod_php script "queue"
am 16.03.2010 16:05:56 von John Iliffe
On Tue, 2010-16-03 at 10:45 -0300, Bruno - e-comBR wrote:
>
> 2010/3/12 Reese
> On 12-Mar-10 13:49, Jonathan Zuckerman wrote:
> On Fri, Mar 12, 2010 at 9:36 AM, Reese
> wrote:
>
> On 12-Mar-10 11:31, Nilesh Govindarajan wrote:
>
> On Fri, Mar 12, 2010 at 6:49 PM, Bruno
> - e-comBR
> wrote:
>
> It's causing a little throuble for me. When a
> PHP script generates a
> bigger
> report(taking about ten
> minutes or more), the user
> seems to be impatient.
> They're doing refreshs on the
> page. So, for each refresh
> apache is
> queuing a
> new script, and just begin
> running this when the queue is
> empty again.
>
> What do you suggest me?
>
> Thank you,
> Bruno Moreira Guedes
>
>
> I don't use mod_php, so don't know
> about its behavior. But I recommend
> you inform the users that the report
> can take upto ten minutes to
> generate and to be patient. That's the
> only solution I see.
>
> Else, if you can make the PHP script 'smart'
> in some way so that a
> popup or other visual indicator will give
> constant, visual feedback
> on the progress of the request. With a
> "Cancel" button that functions
> to kill the original request while blocking
> page refreshes. They can
> start over from scratch if they like.
>
> Reese
>
>
>
>
> ------------------------------------------------------------ ---------
> The official User-To-User support forum of the
> Apache HTTP Server Project.
> See
>
> for more info.
> To unsubscribe, e-mail: users-
> unsubscribe@httpd.apache.org
> " from the digest: users-digest-
> unsubscribe@httpd.apache.org
> For additional commands, e-mail: users-
> help@httpd.apache.org
>
>
> Is there any way to cache the report?
>
>
> You could get the parameters sorted out, then create a cron
> job
> from it and feed it to a .log file. This log file could be
> made
> available to administrators only, the world or something in
> between, depending on where in the file system it is located
> and
> the associated permissions.
>
>
> To eventually ensure the user sees the report when
> it's done being
> generated, you could do some fancy Keep-alive with the
> http request, or just
> have some javascript on the page that automatically
> reloads it, and upon
> reload the script will check to see if there's a
> report built for that user,
> otherwise it checks to see if there's a lock. If
> there's a lock, it stops
> and waits to try again soon. If there is no lock, it
> starts a new report.
>
>
> Or compress and store or mail it to them (and others?),
> starting a new
> log file after each clock cycle.
>
> This is starting to feel like reinventing HTTP access logs. We
> got off
> track somewhere.
>
>
> Reese
>
>
>
> ------------------------------------------------------------ ---------
> The official User-To-User support forum of the Apache HTTP
> Server Project.
> See for more
> info.
> To unsubscribe, e-mail: users-unsubscribe@httpd.apache.org
> " from the digest: users-digest-
> unsubscribe@httpd.apache.org
> For additional commands, e-mail: users-help@httpd.apache.org
>
>
>
>
>
> I would like to thank everyone by this ideas. I'll test each one and
> see what happen :-)
> But if someone knows a way to adjust this behaviour(some 'undocumented
> procedure'), please tell me.
>
> Thanks,
> Bruno Moreira Guedes
>
If you have JavaScript in the client programme, do the PHP request as a
background (AJAX) request. Set the client script so that the request is
locked until a response is received. You should also us a timer to
allow the user to restart in case no response is ever received ;-)
You can also use the client script to cancel the PHP processing if the
client goes away - that is the user gets bored waiting and closes the
session.
Ten minutes seems like a long time for a real person to wait and using
background client processing through AJAX will allow the client to use
his terminal for something more productive during that time.
John
------------------------------------------------------------ ---------
The official User-To-User support forum of the Apache HTTP Server Project.
See for more info.
To unsubscribe, e-mail: users-unsubscribe@httpd.apache.org
" from the digest: users-digest-unsubscribe@httpd.apache.org
For additional commands, e-mail: users-help@httpd.apache.org