On 07/12/10 22:04, Peter Tröger wrote:
Am 07.07.2010 um 20:52 schrieb Daniel Templeton:
Not sure I like that in the JobSession. I mean, it *is* the *Job*Session, but that would mean writing a monitoring tool would require keeping two sessions open.
Completely agreed. The method is now in MonitoringSession.
Is there any need to have more than one MonitoringSession per application? If not we have to make it a singleton. Daniel
As for the filtering, it should be possible to filter on any job attribute. We have not yet discussed job owner as a job attribute, but now that we've opened the possibility of monitoring other users' jobs, I think we have to consider it. I don't see an issue with it. If it's a security problem, then the DRM is free to hide anything that shouldn't be exposed.
Good that we already solved that ;-) We decided earlier to perform filtering on the job list from JobSession with the JobInfo structure. Since the structure already contains the job owner information, the problem is solved.
And I still don't see any resolution for the problem of getting back a list of several hundred thousand jobs. I think we've had this discussion before. Anyone have notes on what we decided?
We also discussed that, and basically agreed on trusting in the OO language's scalability capabilities.
Best, Peter.
Daniel
On 07/06/10 15:16, Peter Tröger wrote:
Hi,
2. Monitoring jobs not submitted by DRMAA - final decision
- Important to be able to obtain information about non-DRMAA jobs which have not ended.
- Desirable to obtain information about non-DRMAA jobs which have recently ended, where "recently" is DRM-defined.
- Importance (and ability to obtain) information about jobs submitted by others unclear. Agreed that if there is support for obtaining information about other's jobs, must support a filter to limit to current user's jobs.
- Desirable to obtain information about non-DRMAA jobs using APIs similar to those used for jobInfo. Use Dictionary type to support DRM-specific info.
After some thinking, I decided to put that into the JobSession interface:
=== snip === interface JobSession { readonly attribute string contact; readonly attribute string sessionName; Job getJob(string jobId); sequence<Job> getSessionJobs(JobInfo filter); sequence<Job> getAllJobs(JobInfo filter); Job runJob(in DRMAA::JobTemplate jobTemplate) raises (???); ... === snip === Non-session jobs are identified by not having the Job::session attribute set. I am still unsure about the "filtering for current user" part, since this would bring us the concept of user name, which was omitted so far.
Best, Peter.
5. Cleaning up the spreadsheet:
No discussion. -- drmaa-wg mailing list drmaa-wg@ogf.org http://www.ogf.org/mailman/listinfo/drmaa-wg
-- drmaa-wg mailing list drmaa-wg@ogf.org http://www.ogf.org/mailman/listinfo/drmaa-wg
-- drmaa-wg mailing list drmaa-wg@ogf.org http://www.ogf.org/mailman/listinfo/drmaa-wg
-- drmaa-wg mailing list drmaa-wg@ogf.org http://www.ogf.org/mailman/listinfo/drmaa-wg