[DRMAA-WG] misssing exceptions and thread safety

Peter Tröger peter at troeger.eu
Tue Mar 2 14:12:23 CST 2010


> Sounds reasonable to me.  At a minimum, all of these very specific  
> state
> exception should inherit from a more general exception in languages  
> that
> support it.

A mandatory exception hierarchy was declined a long time ago, the  
argumentation became even part of the DRMAA IDL 1.0 spec:

"Language bindings MAY decide to introduce a hierarchical ordering of  
the DRMAA exceptions through class derivation. In this case it MAY  
also happen that new exceptions are introduced for behavior  
aggregation. In this case, those exceptions SHALL be marked as  
abstract, to prevent them from being thrown."

>> 1. Can we merge JobAlreadySuspendedException,
>> JobNotSuspendedException, JobTerminatedException into one something
>> like CantApplyToCurrentStateExecption (OGSA-BES approach) and state
>> that the error message should bears current job state ?

I might have missed something, but where did you got these exceptions  
from ? Another point is that your proposal is already reality. The  
decision was made at the F2F meeting in July 2009:

"The former HoldInconsistentStateException,  
ReleaseInconsistentStateException, ResumeInconsistentStateException,  
andSuspendInconsistentStateException from DRMAA v1.0 are now expressed  
as single InconsistentStateException with different meaning per  
function"

I would like to ask everybody to reason ONLY about the DRMAAv2 spec in  
the wiki. Every other document is (very likely) outdated.

Thanks and best regards,
Peter.




>> 2. Guaranteeing atomicity (concerning operation that comes from
>> outside) in DRMAA is almost impossible for the DRMS i know, as  
>> usually
>> there is no "lock on job" operation available in public API.
>>
>> Cheers,
>>
>> On 1 March 2010 15:27, Andre Merzky<andre at merzky.net>  wrote:
>>
>>> Hi Dan,
>>>
>>> Quoting [Daniel Templeton] (Mar 01 2010):
>>>
>>>> There is, however, no need to make the exception explicitly
>>>> optional.  Exceptions are by definition optional.
>>>>
>>> This may be true in this case, but in general I expect exceptions to
>>> be guaranteed on specific circumstances. For example, I would expect
>>> that a suspend() on an invalid jobid will *always* cause an
>>> exception (mandatory), not only sometimes (optional).
>>>
>>> Best, Andre.
>>>
>>>
>>>
>>> --
>>> Nothing is ever easy.
>>> --
>>>  drmaa-wg mailing list
>>>  drmaa-wg at ogf.org
>>>  http://www.ogf.org/mailman/listinfo/drmaa-wg
>>>
>>>
>>
>>
>>
>
> --
>  drmaa-wg mailing list
>  drmaa-wg at ogf.org
>  http://www.ogf.org/mailman/listinfo/drmaa-wg



More information about the drmaa-wg mailing list