UWS 1.1

Patrick Dowler patrick.dowler at nrc-cnrc.gc.ca
Tue May 26 20:28:34 CEST 2015



On 26/05/15 02:38 AM, Paul Harrison wrote:
>>     Well, this is quite fine if the client is a browser - it is totally transparent - but another client (like Topcat) should know about that trick. Honestly, I am not keen with this idea although it limits the resources consumption on server side by avoiding real unlimited wait but by doing like it does. The other solution, as Pat said, is to set a timeout (= max server waiting time). I would certainly do the same, except if the "request redirection" solution is fine for you.
> On of the central design features of UWS is that the server is allowed to make decisions that override the requests from the client in order to save resources - e.g. if the client asks for a destruction time 10 years in the future, the server is allowed to reply with 10 days (or whatever it thinks it can support as a maximum) seehttp://www.ivoa.net/documents/UWS/20101010/REC-UWS-1.0-20101010.html#DestructionTime
>
> A similar reasoning can be applied to WAIT times and indeed the 3rd paragraph of thehttp://volute.googlecode.com/svn/trunk/projects/grid/uws/doc/UWS.html#blocking  section anticipates that the server might return earlier than the WAIT time if necessary and the client should be able to deal with this situation - i.e. read the returned PHASE, and not just assume that it has changed because the server has returned.

Agreed.

Although I think the client should be expected to deal with the redirect 
correctly, they also have to be able to deal with a server that just 
lets the wait run until there is an http timeout and they have to deal 
with the server unblocking for a change they don't care about... in all 
of that, I find I prefer the max wait time on the server side as it is 
consistent with the rest of UWS and easiest to implement. But, I think 
one could provide the convenience of the redirect without violating the 
spec.

Another small fiddly bit: I did implement ?WAIT (with no value) to wait 
until the max wait time, but I see no value in having WAIT=0 be special 
and do the same thing... with http timeouts there are no particularly 
useful wait times that are large enough that a client can't come up with 
a normal value that expresses their actual interest and no one is really 
interested in waiting forever :-) So, in my implementation WAIT=0 does 
exactly that: waits for 0 seconds then returns.

-- 

Patrick Dowler
Canadian Astronomy Data Centre
National Research Council Canada
5071 West Saanich Road
Victoria, BC V9E 2E7

250-363-0044 (office) 250-363-0045 (fax)


More information about the grid mailing list