Hi All,

I am working on a mailing list program for a client, and I am wondering
what tbe hest way to deal with script timeouts is. I realize that I
could use set_time_limit() to increase the script timeout, but that
doesn't handle situations where 1) safe mode is on, or 2) Apache's
timeout is exceeded. These mailings go out to between 5000 and 10000
email addresses, so timeouts are a concern.

It seems to me that the best thing to do would be to fire off a separate
process, perhaps a PHP script that runs directly via the php executable
(a command line script, rather than a .php file that is executed through
Apache).

Is there a way to trigger a process that will then run on its own? The
PHP script running in the browser could then send a message saying
"delivery started" or something, and the separate PHP script that has
been fired would handle the actually delivery. It would run outside of
Apache, and can record success/failure in a database.

Running PHP4.3.9 on RHEL (but I would like a solution that is not tied
to a particular version of PHP or Linux, if possible).

Thoughts?

Sincerely,
-Josh

Hi,

I've done a similar solution (in perl though). Have the browser script
update a database/text/config file.

Have a scheduler (cron on unix, at on windows) execute the script that
will do the background work only after checking the value updated by the
browser script and have it clear it after finishing the job.

I had it every 3 hours and used a text file, depends on tipe of job and
you can have it run up to every minute.

Hope to have helped ;-)

Joshua Beall wrote:[color=blue]
> Hi All,
>
> I am working on a mailing list program for a client, and I am wondering
> what tbe hest way to deal with script timeouts is. I realize that I
> could use set_time_limit() to increase the script timeout, but that
> doesn't handle situations where 1) safe mode is on, or 2) Apache's
> timeout is exceeded. These mailings go out to between 5000 and 10000
> email addresses, so timeouts are a concern.[/color]

A way to manage the timeout could be to generate a small output say after each
100 mails sent (echo ".";), this would keep the page alive for the apache
server. But, no I don't think this is the best option this time.

[color=blue]
> It seems to me that the best thing to do would be to fire off a separate
> process, perhaps a PHP script that runs directly via the php executable
> (a command line script, rather than a .php file that is executed through
> Apache).
>
> Is there a way to trigger a process that will then run on its own? The
> PHP script running in the browser could then send a message saying
> "delivery started" or something, and the separate PHP script that has
> been fired would handle the actually delivery. It would run outside of
> Apache, and can record success/failure in a database.
>
> Running PHP4.3.9 on RHEL (but I would like a solution that is not tied
> to a particular version of PHP or Linux, if possible).[/color]

You could try something like system('php script.php &');
Not sure if that will work in the same way in php as it does in shell.

//Aho

Joshua Beall wrote:
[color=blue]
>
> Is there a way to trigger a process that will then run on its own? The
> PHP script running in the browser could then send a message saying
> "delivery started" or something, and the separate PHP script that has
> been fired would handle the actually delivery. It would run outside of
> Apache, and can record success/failure in a database.
>
> Running PHP4.3.9 on RHEL (but I would like a solution that is not tied
> to a particular version of PHP or Linux, if possible).
>[/color]

The only solutions I know of are:

1) run a daemon process to control the background process and initiate it
from your PHP (rather complicated)

2) start a process which forks and resets it's process group. (afaik
impossible using PHP only)

3) `at now 'php -q background.php'`

HTH

C.

J.O. Aho wrote:
[color=blue]
> You could try something like system('php script.php &');
> Not sure if that will work in the same way in php as it does in shell.
>[/color]

It works exactly the same way; although both processes run concurrently, the
parent process will wait for the child to terminate. See post in
alt.comp.lang.php

C.

Joshua Beall wrote:[color=blue]
> Hi All,
>
> I am working on a mailing list program for a client, and I am wondering
> what tbe hest way to deal with script timeouts is. I realize that I
> could use set_time_limit() to increase the script timeout, but that
> doesn't handle situations where 1) safe mode is on, or 2) Apache's
> timeout is exceeded. These mailings go out to between 5000 and 10000
> email addresses, so timeouts are a concern.
>
> It seems to me that the best thing to do would be to fire off a separate
> process, perhaps a PHP script that runs directly via the php executable
> (a command line script, rather than a .php file that is executed through
> Apache).
>
> Is there a way to trigger a process that will then run on its own? The
> PHP script running in the browser could then send a message saying
> "delivery started" or something, and the separate PHP script that has
> been fired would handle the actually delivery. It would run outside of
> Apache, and can record success/failure in a database.
>
> Running PHP4.3.9 on RHEL (but I would like a solution that is not tied
> to a particular version of PHP or Linux, if possible).
>
> Thoughts?
>
> Sincerely,
> -Josh[/color]


Possibly a cron job running a PHP script that writes and subsequently
reads its own a log file ... containing the settings for the next SQL
query's start row and limit.

http://www.phpfreaks.com/tutorials/28/0.php