On May 19, Moreno Marzolla modulated: ...
From section 3.2.1: "The job will remain in Pending until it receives a Release event from the Job Release operation, which will move it to Running". (I think that the "Pending" state mentioned here is the state labeled as "Start Pending" on Figure 2). From this we where assuming an implicit hold. If this is not the case, is the transition Pending -> Staging In instantaneous? I think that it would be useful to provide a complete description of states and transitions in section 3.2.1 of the document (that is, expanding Table 1).
I would hope this is simply a text versioning issue, and that any of the hold states would be explicitly enabled/disabled by job document content so that the transitions can be instant or blocked on client "release" actions.
What we had in mind was simply to make the transition(s) from states "Executing" -> "Staging Out" -> "Cleaning Up" not instantaneous, so that files do not get immediately purged.
Yes, we do the same thing as you are thinking in WS-GRAM through the use of a hold state between the staging out and cleaning up steps. The other issue Peter is highlighting is something we had to address in WS-GRAM: the namespaces of the local job filesystem and the data access interface may not be identical, so some sort of mapping needs to be exported. In our case, standard GridFTP is the data access (monitoring) interface, so we had to expose the mapping for the client to convert a job output file URI into a GridFTP URL. With a web-service based file access interface, this mapping could probably be wrapped up so that the data access remains relative to the job's output file namespace?
Anyway, according to the current JSDL specification, it is possible to specify DataStaging elements with the "DeleteOnTermination" sub-element set to False, meaning that a given file should NOT be deleted after the job terminates. In this case, even if the transitions "Executing" -> "Staging Out" -> "Cleaning Up" are instantaneous, the user might later access files for which the "DeleteOnTermination" flag was set to false.
Personally, I think that is insufficient in JSDL. You want to be able to pause for safe interlock of 3rd-party data monitoring, but still be able to clean up without having either of: -- client obligation to remove files -- unbounded lifetime of temporary job files after job exits There are jobs where cleanup is not desired, but I do not think that should be considered the same as this output monitoring and synchronization... karl -- Karl Czajkowski karlcz@univa.com