Andrea Aime

GeoServer 2.7.0

• Under Discussion
• In Progress
• Completed
• Rejected
• Deferred

WPS processes can run for a long time, consuming valuable resources on the server side. The WPS 1.0 specification allows for two kind of requests:

• Synchronous requests, best suited for short executions, in which the clients waits for the response on the same HTTP connection that started the execution
• Asynchronous requests, in which the client gets back a link to a status URL, and can poll such link to get information about the execution progress eventually getting the results at that same URL once the process execution has completed

In GeoServer all requests, synchronous or asynchronous, are associated with an executionId, and recent developments added an administration page where the currently running processes can be listed along with their progress.

The executionId is also exposed in the status URL GeoServer returns, as that URL is actually implemented in GeoServer as a pseudo OGC operation, GetExecutionStatus, available only in GET form, whose structure looks as follows:

http://host:port/geoserver/wps?service=WPS&version=1.0.0&request=GetExecutionStatus&executionId=550e8400-e29b-41d4-a716-446655440000

The operation is not really meant to be "constructed" by the client, as its entire URL form is already provided in the Execute response, and thus it's not declared in the Capabilities document.

The objective of this proposal is to allow cancellation of all processes running in GeoServer via the admin GUI, and to allow users to also dismiss a running asynchronous process via a new vendor OGC request.

The WPS 2.0 specification, about to be released, includes a concept of job id and job dismissal, this proposal tries to align as much as possible with it, but stay compatible with the WPS 1.0 schemas and the existing GeoServer implementation of it.

The process status page will be extended, adding a way to select running or completed processes, and have them "cancelled".

In the case of a running process, the process will be cancelled immediately, and any resource pertaining to it will be released. In case of a completed process, this will result in the immediate removal of any resource associated to it (e.g., stored outputs), as opposed to the usual time based resource removal.

Once a process execution is dismissed the server will act as if the process failed, reporting an exception (the dismissed status is not present in the WPS 1.0 schemas).

A new vendor call Dismiss will be added to the capabilities document and a user will be able to call it as a GET request using the following URL structure:

http://host:port/geoserver/wps?service=WPS&version=1.0.0&request=Dismiss&executionId=550e8400-e29b-41d4-a716-446655440000

Similarly to the WPS 2.0 specification, the response to such request will the a ExecutionResponse document. Differently from the WPS 2.0 specification though, the WPS 1.0 response does not foresee a dismissal status, so a process failed one will be used.

GeoServer runs Java processes in thread pools, and provides them a GeoTools ProgressListener.

A process can be cancelled only if it actually uses the ProgressListener, and checks the isCancelledmethod periodically, interrupting execution at once. In order to stop a larger class of processes, all calls to progress and setTaks will also throw an exception when the process status switches to cancelled.

Unfortunately, nothing can be done for processes that are not interacting with the ProgressListener. The WPS 2.0 specification allows the server to advertise if a certain process can be dismissed or not at the process description level, unfortunately the WPS 1.0 specification does not allow any space for extensions, to avoid breaking the schema, no such information will be advertised.

Processes running in a cluster step over two states:

• Being queued, waiting for execution, in a thread pool
• Actual execution

The shared status provided by the ProcessStatusStore, along with the ProgressListener behavior described above, will make sure processes get properly cancelled during execution.

However, we also want to stop processes that are waiting for a free thread in the connection pools, for those the heatbeat timer that periodically marks a process as running will be modified to execute more frequently (once every N seconds, with N being set to 10 seconds and modifiable via a system variable, org.geoserver.wps.heartbeat.interval) and check the status, and inform the ProcessManager of the cancellation immediately

No backwards compatibility issues known.

Project Steering Committee:

• Alessio Fabiani +1
• Andrea Aime +1
• Ben Caradoc-Davies
• Christian Mueller
• Gabriel Roldán
• Jody Garnett +1
• Jukka Rahkonen +1
• Justin Deoliveira
• Phil Scadden +1
• Simone Giannecchini +0

• Email Discussion - 1
• Email Discussion - 2
• Jira ticket