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