bug #163
there is no function to reap jobs in a job or monitoring session
| Status: | closed | Start date: | 08/26/2014 | |
|---|---|---|---|---|
| Priority: | Urgent | Due date: | ||
| Assignee: | - | % Done: | 0% |
|
| Category: | - | |||
| Target version: | - |
Description
Currently the only way to get rid of jobs is closing
and re-opening a session since a session also requires
to store finished jobs.
There is a need to reap job information explicitly
in a standardized way in order to avoid out-of-memory.
History
Updated by Peter Tröger about 8 years ago
- Project changed from DRMAAv2 C Binding to DRMAAv2 Root Specification
Moved to root spec issues, since this is a general problem.
Updated by Peter Tröger about 8 years ago
- Status changed from submitted to accepted
Updated by Peter Tröger about 8 years ago
The OGF-42 meeting decided that a new function is added to the Job interface:
void reap()
The function is intended to let the DRMAA implementation clean up any cached state about this job. The motivating factor are long-running applications maintaining large amounts of job objects as part of a monitoring session.
This function should only work in Terminated states, so that the job is promised to not change its status while being reaped.
Using a reaped job in any subsequent activity should generate some common error.
The language object / struct instance for the job may or may not be still valid after the reap() call. The semantics of this must be specified by the language binding.
Updated by Peter Tröger about 8 years ago
- Status changed from accepted to final review
Updated by Daniel Gruber over 7 years ago
Implemented following function in Univa Grid Engine DRMAA2 C binding:
drmaa2_error drmaa2_j_reap (drmaa2_j job);
Updated by Peter Tröger over 7 years ago
- Status changed from final review to closed
Fixed in July 2015 errata, for both the root spec in the C binding.
(Other formats not available in this archive.