UWS POST PHASE=RUN

[Walter Landry]

I guess my main problem is that I do not like to have jobs that are
not running and may never run.  These zombie jobs make book-keeping
more annoying.

In general, I appreciate the desire for a prediction mechanism, but
that feels like it should be a separate request type.  Instead of
"doQuery", it would be something like "estimate" or "quote".  Then
prediction is synchronous.  If you are happy with the prediction, you
can submit the same query with "doQuery".

Cheers,
Walter Landry

Patrick Dowler <patrick.dowler at nrc-cnrc.gc.ca> wrote:
> UWS allows for the client to specify parameters and the service to
> advertise some limits (max execution time) and predictions
> (quote). Yes, they are notoriously hard to implement :-) There is some
> negotiation that can be performed, but part of that might be that the
> client could change some aspect of the job in order to negotiate a
> satisfactory outcome.
> 
> For example, say I create a job with MAXREC=1e6 and the server
> responds with OK, but destruction is only 1200 (seconds in the
> future). The the client modifies the job to MAXREC=1e5 and the server
> now sets destruction to 3 days in the future. Nothing says the service
> has to adjust limits, but in the current spec they can adjust limits,
> clients can ask for different limits, and failing that clients can
> adjust the job to find a satisfactory limit.
> 
> It would more of a pain to keep creating new async jobs rather than
> negotiate over one of them and IMO changing the job can/should be part
> of the negotiation. This all happens in PENDING phase, before any
> execution, so there is no cancel per se (client could delete the old
> job). So this is "pre-queueing".
> 
> To be fair, I don't see this as a major issue for jobs like TAP
> queries or vospace transfers, but I could definitely see it being
> important for things like processing jobs. In that kind of system, the
> job description now usually contains things like number of cores to
> use, amount of memory, etc... one could easily imagine that request
> for lots of cores and rams could result in a large value of quote
> (waiting in the queue) and reducing one or both might reduce the quote
> so the job runs sooner.
> 
> 
> Pat
> 
> 
> On 04/11/14 10:16 AM, Walter Landry wrote:
>> Why do allow modification of parameters?  All of the queuing systems
>> that I have worked with in the past did not allow it.  If you want to
>> modify parameters, you can cancel the old request and submit a new
>> one.  That is essentially what would happen in the back end anyway.
> 
> -- 
> 
> 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)