Max processing time for the processqueue page (for remote batch processing)

[bluecataudio]

The current processqueue page, even when called from a command line (using curl for example), will stop processing the queue after 60 seconds. This change lets you specify the max processing time in the GET request so that the processqueue page can be used outside of a web browser for batch processing.

Description

Related Issue

Screenshots (if appropriate):

[michield]

I don't think this is a good idea. It opens a potential (D)DOS attack vector. I don't see the need for this, you can just call processqueue regularly. If you want to control this, then it would be better to control it via the config file, instead of via a GET parameter.

[bluecataudio]

Thanks for having a look at this pull request. I don't think it may cause a real DDOS problem, as it just processes the queue, and it's supposed to be a protected API anyway.

The reason for adding this parameter is to make remote calls easier from the command line (processing the returned json with a loop in a batch file is not very nice...).

Also, using a config file is not an option if you use both "batch" remote calls and in-browser queue processing. As far as I understand this 60 seconds limit is only here to avoid timeouts in the web browser, isn't it?

[bramley]

The current processqueue page, even when called from a command line (using curl for example), will stop processing the queue after 60 seconds

This isn't correct. The 60s limit applies to browser-based processing and the remote page processing, which seems to be what you want it for. Perhaps have a new config setting that is used only for remote page processing, identified by $inRemoteCall.

~~Or possibly have no elapsed limit for remote page processing, because it will usually be invoked through a command which won't have the browser-based timeouts.~~ Sorry for that last point. The remote page processing will be limited by the web server's and php maximum execution time.

[bluecataudio]

Thanks! I had not noticed this $inRemoteCall variable. I guess a good solution would be to take the extra max processing time parameter into account for remote calls only.

It is useful to control this time from the url (and not a setting in the config) to make cron jobs easier to setup and modify.

[michield]

Due to #901 Github closed this PR. That was not intentional.