Participants: Peter, Dan, Hrabri - Continuation of discussion about synchronization approach in DRMAA2 - Dan: Use cases from previous mail come down to two major cases - Wait for state transitions to happen, in best case without loosing any of them - Wait for a job to have some state - Lossless transition monitoring is the major problem - Hard to model in a pull API - Too many feasible use cases to just ignore it - Hrabri:Focus on different application layout, instead of covering everything in the API - Conclusion: Transition monitoring is too hard with a pull model - Let transition monitoring be based on an optional callback mechanism in DRMAA2 - Burden of book-keeping / timing issues on the the DRMAA2 library implementation - DRMAAv2 should pre-define as much as possible (callback registration method, callback method signature) - Specific technical realization by the language binding - Might be not implementable for some systems (e.g. DRMAA Grid frontend), therefore optional feature - Conclusion for state waiting - Careful extension of DRMAA1 wait() semantics - Wait for permanent status - "started" or "terminated" - each of them includes several DRMAA job states - Might be realized by two functions (e.g. "waitAnyStarted" / "WaitAnyTerminated") - Reaping as decided before - wait functions on session level take a list of jobs as argument, in order to allow iterative job list processing by the application - Job state information is explicitly thrown away by deletion methods - no implicit reaping based on returned state information - Dan raised new open issue - consideration of "re-scheduled" as monitorable job status - Schedule for working group - DRMAAv2 presentation at Sun HPC workshop in Regensburg, Sept. 8th - Presentation of all major DRMAA2 concepts at OGF27 by Dan - "feature complete" until October - Final document submission at the end of the year - Hopefully proposed recommendation status at OGF28, big meeting (Dan, Peter, Daniel, ...)