UWS 1.1

[Paul Harrison]

Hi UWS 1.1 implementors!

> On 2015-05 -26, at 09:58, Grégory Mantelet <gmantele at ari.uni-heidelberg.de> wrote:
> 
> Hello Pat, Mark and Grid,
> 
>    UWS 1.1 will be also implemented in the CDS/ARI's UWS Library. I have still few things to test or finish on it, but basically job list filtering and the blocking behaviour are working. Developments are still in progress but available on GitHub in the branch "uws1.1": https://github.com/gmantele/taplib/tree/uws1.1
> 
>    @Mark: if you want, I can provide you a .war archive with a very simple uws that you could deploy locally in order to test Topcat on it.
> 
> 
>    About the blocking behaviour, I have two comments:
> 
>    First, the UWS Lib. is managing jobs completely in memory. This lets be notified immediately about a phase change thanks to a listener (already in place in the lib. for a while now). Thus, no polling is performed.
> 
>    Second, and it is the most important point for me: the client abortion. As Pat said, there is no way to detect client abortion (i.e. the client is not waiting any more for a server response)....at least using the Servlet API in Java. A such detection would be possible using directly sockets, but this part is hidden by the web application server (e.g. Tomcat).
>    It is now several days I am spending to find a solution, but the only work-around I found was to send after a while a redirection to the same request (with the ?WAIT parameter ; with a reduced waiting time if some was set). In this way, if the client gave up, the redirection is not done, and otherwise the server receives a new waiting request and executes it. In both cases, the original waiting request is finished on server side.
>    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) see http://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 the http://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.

As an aside (I am not suggesting this for UWS 1.1) - our services are starting to look rather old fashioned nowadays, as this sort of sophisticated “two way” flow control in done with web-sockets nowadays - we should perhaps discuss this in Sesto too.
> 
>    By the way, I also want to briefly point out that the same problem (client abortion detection) exists also for TAP synchronous requests.
> 
> 
>    To conclude this email, I would like to know whether I have understood well about the ARCHIVED phase. A job is going in this phase ONLY IF the destruction time is reached. Is it right or is there a manual way for a user to put a job in this phase?
>    Then, I suppose that a normal ?action=delete request is enough to anyway really delete this job, isn't it ?
> 

There is no direct manual way for the client to put a job into the ARCHIVED phase - it is again a sever decision (at least for UWS 1.1 for backwards compatibility) as to whether to implement an ARCHIVED phase. I think that it would be allowable for a server to decide to put a job into the ARCHIVED phase even with an explicit ?action=delete,

Regards
	Paul.