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?
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