[drmaa-wg] Another Argument for a DRMAA_ERRNO_UNSUPPORTED_ATTRIBUTE Error Code

[Daniel Templeton]

Roger Brobst wrote:

>I think you have correctly identified that the error codes
>specified in the C-lang spec for drmaa_set_attribute() do
>not adequately describe the situation when an attribute is
>not supported.
>
>Should it ?
>I did not locate any text in the spec which indicates that
>it is an error to specify an unsupported (or unrecognized)
>attribute.
>On the other hand, I also did not locate any text which
>indicates that unsupported attributes will be ignored.
>
I think you just discovered a new tracker item. :)  It should be
specified one way or the other.  Otherwise, DRMAA applications will not
be portable across implementations.

>I do distinctly recall discussion at GGF-6 (2002) related
>to an ISV providing several DRMS-specific attributes for
>several known implementations (where at most one 
>implementation is deployed for the session).  
>Bill Nitzberg made the observation, and Andreas effectively
>made the case that Job Categories are a more appropriate
>mechanism.
>
Job categories are at a courser granularity.  An ISV should be able to
deploy a DRMAA app without having to alter the configuration of the
DRMS.  Besides, combinatorics says that job categories will rapidly
become no longer viable as a solution to this problem when the number of
supported optional attributes gets above 2-3.  We have, what, 6?

>I don't think I fully understand the situation described
>below:
>  
>
>>(Caching the supported argument list doesn't help if
>>the list can change during the lifetime of the DRMAA
>>application, as is the case with SGE.)
>>    
>>
>
>It would seem that if the set of supported attributes are
>changing during a session, then validation should be
>performed by the 'Job Valuator' when drmaa_run_job is
>invoked; not at the time each attribute value is set.
>  
>
You bring up an interesting point.  Should a job template be aware of
such changes in the DRMS?  Right now, ours are.  I can easily see the
point that a mutable job template is a moving target and could drive a
developer nuts.  On the other hand, a job template may be very long
lived.  We completely take away the control from the admin if we allow a
job template to hold onto an environment that should no longer exist.

Honestly, what makes sense to me at this moment is to specify the list
of supported optional attributes as immutable for a given
implementation.  In cases like ours, where our support of an attribute
is dependent on the configuration of the DRMS, we should return
something like DRMAA_ERRNO_DENIED_BY_DRM on job submission.  Thoughts?

Daniel

>In a previous e-mail, Daniel Templeton wrote:
>  
>
>>That is a solution, but I have a fundamental problem with
>>making developers jump through hoops to interpret the
>>information returned from a call.  An error code should
>>clearly indicate what the error is.  Overloaded error codes
>>are bad.  They lead to very bad error handling practices.
>>
>>Think about the man page.  Do you want to explain to
>>developers that DRMAA_ERRNO_INVALID_ARGUMENT means either
>>that an argument was bad, *or* that the attribute is
>>unsupported, and that they'll have to retrieve and parse
>>through a list of all the supported attributes to tell the
>>difference?  Only 10-20 strcmp's later you'll know what
>>the error meant!  What a bargain!
>>
>>(Caching the supported argument list doesn't help if the
>>list can change during the lifetime of the DRMAA
>>application, as is the case with SGE.)
>>
>>Daniel
>>
>>Roger Brobst wrote:
>>
>>    
>>
>>>Given that the C-lang interface specifies the function
>>>drmaa_get_attribute_names, it would seem that a Java
>>>binding which leverages a C-lang implementation could
>>>determine the supported attribute names.
>>>
>>>-Roger
>>>
>>>
>>>In a previous e-mail, Daniel Templeton wrote:
>>> 
>>>
>>>      
>>>
>>>>I just uncovered a bug in the DRMAA Java language binding,
>>>>that stems directly from the DRMAA_ERRNO_INVALID_ARGUMENT
>>>>error code being used to indicate that an optional
>>>>attribute is unsupported.  
>>>>
>>>>Rather obviously, the bug is that the property setters throw
>>>>InvalidArgumentException instead of UnsupportedAttributeException
>>>>for unsupported attributes, because the Java language binding 
>>>>can't tell from the C binding whether the attribute is actually
>>>>unsupported, or if the attribute is supported, but the argument
>>>>to the setter is invalid.
>>>>
>>>>Daniel
>>>>
>>>>   
>>>>        
>>>>
>
>  
>

-- 
***************************************************
*        Daniel Templeton   ERGB01 x60220         *
*       Staff Engineer, Sun N1 Grid Engine        *
***************************************************
* "Roads? Where we're going we don't need roads." *
*                    -Dr. Emmett Brown            *
*                     Back to the Future (1985)   *
***************************************************