TAPRegExt: sync/async preference

[Paul Harrison]

> On 10 Jul 2025, at 10:56, Mark Taylor via dal <dal at ivoa.net> wrote:
> 
> To me the existing situation of having two options for submitting
> a job works well for clients, and my impression is that users
> understand it OK.  Has the understanding of client and server
> requirements for short- and long-running jobs changed since
> TAP 1.0 was specified with both sync and async endpoints?
> 
> If services don't want to work synchronously under the hood they
> can provide a sync facade on their asynchronous behaviour,
> which I believe is what some implementations do already.

Indeed it is a suggested model of implementation in the standard - https://www.ivoa.net/documents/UWS/20161024/REC-UWS-1.1-20161024.html#SynchronousService and of course it could be arranged to be done without the redirection suggested there.
> 
> I would also actually say it's a feature (though maybe an unintended 
> one) that sync jobs typically time out before too long, indicating 
> that the submitted query is actually expensive, which may not be
> obvious to the ADQL author.
> 

I agree and it might not just be that the individual query is expensive, but that the server is overloaded with many clients and cannot afford to keep all of the synchronous connections open.


> On 9 Jul 2025, at 18:34, Patrick Dowler via dal <dal at ivoa.net> wrote:
> 
> 2. We more carefully define TAP-sync to be able to respond with "this
> request is actually
> executing in async mode, here is the UWS job URL"

In the case of a timeout on the synchronous call the response could be a 504 with a job URL in the body. If the call succeeds then the normal response is sent, so that a “dumb” client does not need to do anything special. Timeouts on the async job could be adjusted so that it will be killed fairly quickly anyway, but extended if the client makes some effort to find out the status of the job. If the service does not want to allow this opportunity to “hook in” to the async behaviour it just responds with a standard DALI error.

Paul.







-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.ivoa.net/pipermail/dal/attachments/20250715/adba1d3b/attachment-0001.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 2893 bytes
Desc: not available
URL: <http://mail.ivoa.net/pipermail/dal/attachments/20250715/adba1d3b/attachment-0001.p7s>