Add a way to cancel a scheduled action
If would be nice if there were a way to cancel a HTTP-request that is associated with a call to @ixsl:schedule-action@. This would allow the users of an application to cancel loading a document if it takes too long.
An id would be to put an identifier attribute on
<ixsl:schedule-action> and than use that id as a parameter of the cancel-instruction.
#1 Updated by Debbie Lockett about 1 year ago
- Status changed from New to In Progress
- Assignee set to Debbie Lockett
- Priority changed from Low to Normal
- Applies to JS Branch 1.0 added
Quite right - we need to be able to abort HTTP requests that take too long.
First solution: when using ixsl:schedule-action/@http-request, allow use of @wait to provide a timeout value (in milliseconds). This timeout can be set on the XMLHttpRequest object, so that a request will be aborted if a response is not received within that time.
In order to know when such a request abort has happened, we trigger a custom event "httpabort" on the Window object, which can then be handled using an event-handling template rule in the XSLT.
It would indeed be nice to allow users to trigger an event that aborts an existing HTTP request, but working out how to do that will require more work (and more changes in server side Saxon). So the solution above will do for now.
This solution already requires server side Saxon 9.8 changes (to allow more than one attribute on ixsl:schedule-action again), so will not be available until the next maintenance release is out (220.127.116.11).
Changes (for IXSLScheduleAction) have been committed on 9.8 and trunk; Saxon-JS code changes have been committed on 1.0 and trunk.
#2 Updated by Debbie Lockett 11 months ago
As well as allowing a timeout to be specified for schedule-action HTTP requests (as specified by ixsl:schedule-action/@http-request), we should also allow a timeout to be specified for schedule-action document retrieve HTTP requests (as specified by ixsl:schedule-action/@document).
Further changes in IXSLScheduleAction.java to update compile-time validation of ixsl:schedule-action attributes: must have at least one attribute, but not both @http-request and @document. Committed on 9.8 and trunk.
This allows @wait can be used with either @http-request or @document to specify a timeout for the relevant requests.
#3 Updated by Debbie Lockett 11 months ago
Various further changes committed on 1.x and 2.0 branches:
Can now cancel HTTP requests (including those for document fetches) by specifying a timeout using @wait, or by aborting
Aborting is made possible by the fact that ixsl:schedule-action now returns the associated XMLHttpRequest (XHR) objects (when called with @document or @http-request), rather than returning nothing. This means abort() can be called directly on the XHR object e.g. using ixsl:call(), for instance triggered by user interaction.
The relevant methods in BrowserPlatform have been updated to allow this (e.g. makeHttpRequest, asyncGet, asyncGetXml now return XHR objects)
The tempOutputState for the new context for the called template (i.e. the scheduled action) is set to false, to allow the result of ixsl:schedule-action to be stored in a variable
For asynchronous document fetches (ixsl:schedule-action with @document) if the document pool holds an XError (as is the case when the document fetch fails because of an error, or abort, or timeout), then we now retry to fetch the document, and update the entry in the document pool.
When ixsl:schedule-action/@document is used to fetch a single document, the instruction returns a single XHR object. When it is used to fetch multiple documents, it returns an object containing multiple XHR objects indexed by absolute URIs.
When an XHR specified by ixsl:schedule-action/@http-request is terminated because of an error, timeout or abort event, the called template is invoked (i.e. this is treated as an alternative to receiving a response from the HTTP request). In this case the context item (which is usually a map representation of the HTTP response) is an XDM map with information about the request termination: with entries for keys 'status' (with value 0), 'message' (a Saxon-JS error message), 'type' (the type of the event which caused the request to end, i.e. error|timeout|abort), and 'error' (a Saxon-JS internal error code).
Various tests committed in svn/tests/saxon-js/http (Servlex webapp for testing different HTTP requests).
Please register to edit this issue