Another Argument for a DRMAA_ERRNO_UNSUPPORTED_ATTRIBUTE Error Code
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) * ***************************************************
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
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 cearly 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) * ***************************************************
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 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. 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. -Roger 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
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) * ***************************************************
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.
The current IDL spec seems to make a clear description: "In the job template there is a distinction between mandatory and optional attributes. A language binding implementation MUST provide implementations for all DRMAA attributes, both required and optional. The setter and getter implementations for optional attributes MUST throw UnsupportedAttributeException in languages which support exceptions. In languages which do not support exceptions, the optional attribute setters and getters MUST return some form of error. The service provider implementation SHOULD then override the setters and getters for supported optional attributes with methods that operate normally." and: "5.6.26 UnsupportedAttributeException: The given job template attribute is not supported by the current DRMAA implementation." In sum, it is specified to be an error if you use an unsupported attribute. If we have a new C-binding document, based on the IDL-spec, then everything should be fine !?
(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.) ... 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?
From the viewpoint of an application developer, I have a very bad feeling with this. I would never expect a change of the list of supported optional attributes, especially not during the runtime of my application. If the admin wants to do some reconfiguration, she is reponsible of considering still running applications. If you really think that this a useful feature at all, I would support the DRMAA_ERRNO_DENIED_BY_DRM suggestion. However, the spec really needs to make this explicit. Peter.
======== Regarding specifying unsupported attributes ... The C-lang and current IDL spec have provisions for handling both required and optional DRMAA attributes. The 3rd type of attribute, DRMS-specific, was intentionally not discussed in the C-lang binding spec because they do not impact the API. From DRMAA's perspective they are simply attributes which are not named with the DRMAA_ prefix. Since the C-lang binding has the caller provide the attribute name and value, there is no linkage problem if the underlying implementation does not understand the DRMS-specific attribute. How does the current IDL spec support DRMS-specific attributes, keeping in mind that the end customer should be able to choose the DRMAA implementation leveraged by the ISV software ? Explicit getters/setters for each attribute would seem to be problematic (certainly from a linkage perspective). ======== Regarding the set of supported attributes changing ... I think the C-lang binding spec should document that the value output by drmaa_get_attribute_names (and drmaa_get_vector_attribute_names) should be valid for the lifetime of the drmaa session. -Roger In a previous e-mail, Peter Troeger 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.
The current IDL spec seems to make a clear description:
"In the job template there is a distinction between mandatory and optional attributes. A language binding implementation MUST provide implementations for all DRMAA attributes, both required and optional. The setter and getter implementations for optional attributes MUST throw UnsupportedAttributeException in languages which support exceptions. In languages which do not support exceptions, the optional attribute setters and getters MUST return some form of error. The service provider implementation SHOULD then override the setters and getters for supported optional attributes with methods that operate normally."
and:
"5.6.26 UnsupportedAttributeException: The given job template attribute is not supported by the current DRMAA implementation."
In sum, it is specified to be an error if you use an unsupported attribute. If we have a new C-binding document, based on the IDL-spec, then everything should be fine !?
(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.) ... 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?
From the viewpoint of an application developer, I have a very bad feeling with this. I would never expect a change of the list of supported optional attributes, especially not during the runtime of my application. If the admin wants to do some reconfiguration, she is reponsible of considering still running applications. If you really think that this a useful feature at all, I would support the DRMAA_ERRNO_DENIED_BY_DRM suggestion. However, the spec really needs to make this explicit.
Peter.
I believe the way we phrased it is that introspective languages, such as the Java platform, will use explicit getters and setters. Non-introspective languages, like C, will use the general getter and setter function from the original DRMAA spec. Daniel Roger Brobst wrote:
======== Regarding specifying unsupported attributes ...
The C-lang and current IDL spec have provisions for handling both required and optional DRMAA attributes.
The 3rd type of attribute, DRMS-specific, was intentionally not discussed in the C-lang binding spec because they do not impact the API. From DRMAA's perspective they are simply attributes which are not named with the DRMAA_ prefix.
Since the C-lang binding has the caller provide the attribute name and value, there is no linkage problem if the underlying implementation does not understand the DRMS-specific attribute.
How does the current IDL spec support DRMS-specific attributes, keeping in mind that the end customer should be able to choose the DRMAA implementation leveraged by the ISV software ? Explicit getters/setters for each attribute would seem to be problematic (certainly from a linkage perspective).
======== Regarding the set of supported attributes changing ...
I think the C-lang binding spec should document that the value output by drmaa_get_attribute_names (and drmaa_get_vector_attribute_names) should be valid for the lifetime of the drmaa session.
-Roger
In a previous e-mail, Peter Troeger 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.
The current IDL spec seems to make a clear description:
"In the job template there is a distinction between mandatory and optional attributes. A language binding implementation MUST provide implementations for all DRMAA attributes, both required and optional. The setter and getter implementations for optional attributes MUST throw UnsupportedAttributeException in languages which support exceptions. In languages which do not support exceptions, the optional attribute setters and getters MUST return some form of error. The service provider implementation SHOULD then override the setters and getters for supported optional attributes with methods that operate normally."
and:
"5.6.26 UnsupportedAttributeException: The given job template attribute is not supported by the current DRMAA implementation."
In sum, it is specified to be an error if you use an unsupported attribute. If we have a new C-binding document, based on the IDL-spec, then everything should be fine !?
(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.)
... 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?
From the viewpoint of an application developer, I have a very bad feeling with this. I would never expect a change of the list of supported optional attributes, especially not during the runtime of my application. If the admin wants to do some reconfiguration, she is reponsible of considering still running applications. If you really think that this a useful feature at all, I would support the DRMAA_ERRNO_DENIED_BY_DRM suggestion. However, the spec really needs to make this explicit.
Peter.
-- *************************************************** * 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) * ***************************************************
participants (3)
-
Daniel Templeton -
Peter Troeger -
Roger Brobst