User defined timeout for synchronous /result

[soxofaan]

Feature idea that came up will discussing slow synchronous processing requests:

Let the user (optionally) define a maximum time to spend on a synchronous /result request:
e.g. "if this takes more than 20 seconds, you can just abort this, I won't be looking at the result probably"

Example use case: interactive viewer, where user is relatively quickly panning and zooming around.

Backend can then free computing resources more efficiently.
And ideally, if backend can reasonably predict how long a particular request will take, it can even avoid burning resources that would be wasted.

[m-mohr]

Example use case: interactive viewer, where user is relatively quickly panning and zooming around.

IMHO this use case only makes sense with the secondary web services, not with /results?!

[m-mohr]

Isn't it pretty hard for a user to estimate the runtime? I'm also not sure a user would set this. It would not be nice if he sets 20secs and result would have been there after 21secs. That wastes even more money. A process may not even have started after 20secs if the back-end is busy...

Additionally, there's also the budget field which stops processing after a certain amount of budget spent, not the time frame. This would avoid burning too much budget.

So right now I don't see much use in this and would vote for not implementing it.

[soxofaan]

Indeed, the secondary services would be a good fit for that use case I gave there,
but one can imagine other interactive apps that would require /results directly because the predefined secondary services don't fit their needs.

Isn't it pretty hard for a user to estimate the runtime? I'm also not sure a user would set this.

Sure, this would not be for users we're currently have in mind (exploration in jupyter for example). I was more thinking about third party apps that integrate with openEO and don't want to slam the backend with wasteful requests.

A process may not even have started after 20secs if the back-end is busy...

This feature would allow the backend to lower the load by prematurely aborting requests that wouldn't meet the deadline.

So right now I don't see much use in this

At the moment there is indeed no concrete use case (except maybe for the secondary services). It's just an idea I wanted to park here.

[m-mohr]

Okay, good. Assigned to "future" milestone for now.

[m-mohr]

Might also be relevant in the federation context:

@soxofaan wrote:

While this will not be in the openEO API spec before version 1.3 or later, we can put it in federation extension.
The aggregator can then use this feature to actively align the synchronous processing timeouts across its upstream back-ends.

[m-mohr]

One thought that came up is that it's also unclear how to communicate what the default timeout is.

[soxofaan]

indeed, makes sense to put this information in the capabilities doc (or something alike). Could also list other constraints like maximum upload/download file size limits