UWS 1.1 job list, sorting NULL values

[Grégory Mantelet]

Hi Kristin, Paul,

     Thank you ; these filters are now clearer for me: they both work 
only with startTime, and ignore the jobs whose startTime = NULL. I am 
starting implementing them in my library this week.

     I agree also to the moment when startTime should be set: only when 
going into the EXECUTING phase. Actually, after some checks, it appears 
that I had already implemented this behavior correctly in my 
UWS-Library...so I do not have anything to change.

     Now, just a little note about endTime: when going from PENDING to 
ABORTED, I have indeed no startTime, but I have an endTime set at the 
date-time when the abortion has been done. I do not know whether it 
makes sense for you. My idea for that was that the job has never been 
started, but is anyway in a "finished" state, then represented by a 
not-NULL endTime.

     Otherwise, the only case when a job can be set into the ERROR phase 
without a startTime, is when an internal error of the UWS mechanism 
happens. Thus, errors like validation/preliminary checks (e.g. ADQL 
query validation) are part of a job and are then reported as error in a 
job description where startTime is NOT NULL. Since UWS is a generic 
protocol, I think that such validation or pre-checks should not be done 
externally to a job execution, except if is specified explicitely in the 
protocol. Is it right?

Regards,
Grégory


On 10/19/2015 01:41 PM, Paul Harrison wrote:
>> On 2015-10 -19, at 11:39, Kristin Riebe <kriebe at aip.de> wrote:
>>
>> Hi Paul, GWS,
>>
>> thanks for the clarification! I think it makes sense to ignore the jobs
>> with no startTime. Just one more thing about the startTime definition:
>>
>>> * There is no creationTime property defined in UWS (so AFTER and LAST
>>> work only on startTime)
>>> * StartTime is the time at which a job is put into the EXECUTING phase -
>>> so will be NULL before this (i.e. in the PENDING phase)
>> I take it that this also means that jobs in QUEUED-phase do not have a
>> startTime yet and thus won't be listed as well.
>>
> That one is more nuanced… I would say again that the UWS has not actually started the job when in the QUEUED phase, so startTime should again be NULL and the job not appear in the filtered lists. However, I can see that it is possible to reach the situation that there are a large number of QUEUED jobs that would mean that filtering would be useful- so that this might be an argument for introducing a creationTime property  (I had not thought of this in the last email!)  I think that we cannot introduce this at the RFC stage of the standards process though, so we just accept that the time based filters are only useful for jobs that have been EXECUTING at some point.
>
>
>> Pending jobs can also be aborted by the user, deleted, or put into ERROR
>> phase, if e.g. a validation check fails.
>> So, coming back to Grégory's additional question:
>>
>>>> Additional question: I consider jobs in ERROR or ABORTED phase as
>>>> finished. In this sense, the start- and endTime should be set to
>>>> something different from NULL (possibly to the same date-time if the
>>>> job failed or has been cancelled either immediately or really fast).
>>>> So, for me, only jobs in PENDING phase has a start- and endTime set to
>>>> NULL. Is it wrong?
>> Should jobs that are aborted or put into ERROR-phase directly from
>> PENDING phase get a startTime set to the time of error/abortion or have
>> no startTime at all?
>>
> If a job goes from PENDING to ABORTED then I think it would never have had a startTime, which is only set when the job goes into the EXECUTING phase.
>
> If there is no objection to the conclusions in this thread, I will make a slight amendment to the UWS standard document to make it clearer so that the time filters apply to startTime and when the startTime is set.
>
> Regards,
> 	Paul.
>
>