Re: [ptp-dev] Updated Resource Manager Schema

[Dave Wootton <dwootton@xxxxxxxxxx>]

Al
I have no objection to the 'includeTrace'
keyword in the error-message element. I'm not sure it's useful though.
My thinking is that this message is what appears with a red x in the upper
left corner of the run configuration dialog. I would expect a stack trace
to be useful only for diagnostic purposes, and then only where it wasn't
clear how we got to the point of the traceback. 
Dave

From:	"Albert L. Rossi" <arossi@xxxxxxxxxxxxx>
To:	Parallel Tools Platform general developers <ptp-dev@xxxxxxxxxxx>
Date:	01/18/2011 02:21 PM
Subject:	Re: [ptp-dev] Updated Resource Manager Schema
Sent by:	ptp-dev-bounces@xxxxxxxxxxx

---

Dave

> On second thought, separate files are probably the only reasonable
way to 
> deal with this. With what I was thinking, the job-attribute element
would 
> itself contain an element that was some sort of tag identifying the
> configuration that it was applied to, and then there probably needed
to be 
> an element specified previously in the file that specified what the
> configuration defined in the file was. So you still have a separate
file 
> for each permutation of for instance OS, but now with the clutter
of 
> job-attribute elements that don't apply to that OS and an additional
> element keyword used to filter them. 
> 
> Doing this I think also means being able to generically specify in
some 
> way system attributes to filter against. I'm not sure how to do that
in a 
> generic open-ended way.
> 
> Maybe the filename of the file should be intended to be descriptive,
> although there is no requirement that the user preserve the name,
and 
> comments in the top of the file specifying the configuration it applies
> to.
> 

This was my orginal thought as well (see the first annotation).  I
will go ahead then and remove those added attributes for job-attribute.


> >We can add a "validate" element.  How would you
specify it?  Would these 
> two uses 
> ><validate>
> >   <regex>...</regex>
> ></validate>
> 
> ><validate>
> >   <acl>-rwxr-xr-x</acl>
> ></validate>
> 
> I think these forms in addition to what you have work for me.
> 
> Another question here is what sort of error message gets generated
when 
> validation fails? Will this generate error messages that name the
field 
> and explain what's wrong? Do we need a way to specify an error message
> text for when a job attribute fails validation? Maybe <message>
needs to 
> be an element of a <validate> element.

I'll add an optional <error-message> element, but it would be simple
to report field name; I would assume we would want to include the stack
trace optionally as well; so maybe <error-message includeTrace="false">...

> 
> I'm concerned about the volume of data that gets sent back to the
client 
> for stdout/stderr by a real application. I'm not sure how much data
real 
> applications write to either. If an application is writing megabytes
of 
> data to stdout, then I'm afraid of saturating the network connection.
My 
> view has been that PTP should work well even wih a cable modem/DSL
> connection of reasonable speed.
> 
> If there's huge amounts of data sent to stdout, then I think the user
> needs the option to keep the data on the machine where the app is
running, 
> by specifying redirection. If I do something like 'ssh remote_node
my_app 
> > stdio_file 2>&1' doesn't the data stay on the remote node?
Note this 
> breaks the job id notifiacation Greg mentioned.

I agree that the user should be able to turn off the streaming of the stdout
if it is voluminous.  Something like tail -f on stdout would be useful,
too.  We not only have a scalability issue with network, but if all
of stdout is saved in Eclipse we could easily provoke an OutOfMemoryError.

Al
_______________________________________________
ptp-dev mailing list
ptp-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/ptp-dev