[solved] Retry with new instance.

[IanD]

Hi,

We have a PHP script that runs some MySql queries, it is for reporting and these queries can take up to a minute. That is not a problem for us.

The problem is after x seconds, LiteSpeed restarts the process with:

[NOTICE] Retry with new instance.

In the log file.

If I'm watching 'mytop' - I can see the first MySql process running and then I can see an identical query running from the 2nd process when a new instance is started.. and then another one sometimes from a 3rd retry.

All these new instances are making original query take longer.

I'm sure this is pretty basic, but how can I stop this? I presume there is a timeout setting I can change? Or just turn off the retries?

Many thanks,

Ian

[NiteWave]

please try increase:
http://www.litespeedtech.com/docs/we...g/#connTimeout
to over 60 seconds

what's the current value? 30 seconds?

[IanD]

It is currently 30 seconds.

The problem is, I want to keep this as low as possible as we get a some DDoS problems. The server is getting over 1 million visits a day so I wasn't keen to increase this for every connection.

I can try increasing it to 60 though and see what happens.

Is there any way to turn off the 'retrying' feature? Just have it fail if it hits 60 seconds?

The restarting of a long process just makes things worse as the problem just escalates more with each restart.

Many thanks,

Ian

[NiteWave]

Is there any way to turn off the 'retrying' feature? Just have it fail if it hits 60 seconds?

not sure if set "Retry Timeout (secs)" of the lsphp5 ext app to a big number will help or not --- I've never tried it, just FYI.

for long running php script, not sure if you can run it in command line, i.e., lsphp5 abc.php, if so, the connection time out between lsphp5 and lsws won't take effect, you can run abc.php as long as possible.

[IanD]

Thanks.

I'll give the Retry Timeout setting a go.

[IanD]

Unfortunately the settings don't seem to make any difference, this still happens after 60 seconds:

2011-01-16 23:50:29.702 [NOTICE] [86.20.198.21:42054-0#APVH] Content len: 0, Request line: 'GET /test.php HTTP/1.1'
2011-01-16 23:50:39.004 [NOTICE] [205.213.216.254:10736-0#APVH] No request delivery notification has been received from LSAPI process:27784, possible run away process.
2011-01-16 23:50:39.004 [NOTICE] [205.213.216.254:10736-0#APVH] Retry with new instance.

My settings are:

Initial Request Timeout (secs) 600
Retry Timeout (secs) 600

Under External App - lsphp5

Any more ideas? Should this work, is it a bug?

Thanks.

[NiteWave]

can you try other 2 suggestions in my previous posts? to try them first anyway if possible. this is to identify where the problem is. if one workaround can resolve the issue, it'll help a lot for the final solution, and tell where the correct direction is.

[IanD]

please try increase: http://www.litespeedtech.com/docs/we...g/#connTimeout
to over 60 seconds

I've increased in to 60 seconds. I really don't want to increase it more than that.. It's a very busy server and these problem requests must only be ~ 200 / 10M+ requests a day.

Running the script on the command would work in regards to not having the 'retry new instance'.

Updating all legacy systems that are run so infrequently to integrate with a command line php script.. it's a lot of work I'd rather not do.

Much rather LiteSpeed just didn't retry long running scripts

[NiteWave]

So, if litespeed can increase connection timeout for specific php script, it'll resolve your issue ideally.

[mistwang]

I think you may have a really old build of lsphp5, if yes, try rebuilding PHP again with latest PHP LSAPI. lsphp5 should send back a request received notification for each request, then LSWS will wait till the request finish, not timeout and try again.

If you use latest LSAPI, and set "LSAPI_ACCEPT_NOTIFY" environment variable for lsphp external app, should remove it.

2011-01-16 23:50:39.004 [NOTICE] [205.213.216.254:10736-0#APVH] No request delivery notification has been received from LSAPI process:27784, possible run away process.

It is the root cause.