Page History

...

There are no alarm types for sequences of values, because the alarm can only be triggered by a single value. This means that <type>Seq property may raise an alarm and the client may subscribe to the alarm by passing Alarm<type> CORBA object, but the callback is invoked for each element in the sequence. For example, if 4 values in a sequence go over a certain limit, the callback will be invoked 4 times.QUESTION: This is how <type>Seq is implemented in C++ (I just checked the code and did not test its actual behavior, so it could be wrong), and I added these sentences here. However, I think it is not a good implementation because, from the view point of the client, the client cannot know which element raises an alarm because Completion or CBDescOut structures do not have a field which holds the index of the element.
I personally think that the alarm is not necessary for Seq type. If the device server developer needs to define an alarm for Seq type, he can extend BACI property to support alarm by himself and the alarm condition should be defined by the developer (e.g. if average of all elements go over a certain value). I cannot come up with a good usage of the current alarm implementation for Seq types in C++.
My suggestion is that we explicitly state that BACI specification does not officially provide alarms for Seq types. This means that the client may still use the existing C++ BACI Seq type properties, but it won't be officially supported and jBACI won't also implement the alarms for Seq types.
Is this a reasonable solution?
A process subscribes to alarms via a method that is part of all RO (read-only) properties. Following is the code from the ROdouble property; for other types all occurrences of double have to be replaced correspondingly:
Subscription new_subscription_Alarm(in Alarmdouble cb, in CBDescIn desc);QUESTION: The method name was formally new_subscription_Alarmdouble, but as far as I see baci.idl, its name was new_subscription_Alarm and the method name is the same for all types. I think it is better to modify this specification in this case. Is it OK?
Note that, even if the same method name is used for different types, type checking will be still done by the compiler by checking the type of the first argument (Alarmdouble in this case).
Only properties of type RO have alarms, as RW properties should not even be able to set values in the alarm ranges. The method returns a Subscription object, which has to be used to destroy the subscription to the alarm events. The Subscription object is the event source interface. It is also the superclass for monitors (see next section).
interface Subscription{
// temporarily suspends dissemination of event callbacks.
void suspend();
// resumes dissemination of callbacks. Ignored if no previous suspend occured.
void resume();QUESTION: For monitoring purpose, if resume() is called after suspend, when shall the first timer trigger be invoked? Immediately after resume() invocation? Or, the time shall be aligned to start_time? If I were a client developer, I would expect that the timer trigger is always aligned to start_time so that the callback is called, for example, at 0:0:0, 0:0:10, 0:0:20, 0:0:30, … if we set the time interval to 10 seconds.
The same discussion goes for the case where the time interval is changed by set_timer_trigger().
// stops dissemination of event callbacks and releases all resources.
void destroy();QUESTION1: Is there any specification (in CORBA or ACS) about what the servant should do when a method is called after destroy() is called. This could happen when a client has several threads, and one thread may call destroy() and, right after that, another thread may call another method.
QUESTION2: Is this destroy() method a standard method to destroy a remote CORBA object? If so, how CORBA ORB responds to the client when a remote object is destroyed (or being destroyed).
QUESTION3: Is there a good document about the lifecycle of the dynamically created CORBA objects. Particularly, I would like to know how such CORBA object shall be implemented in Java (e.g. what methods should be implemented to support the lifecycle of CORBA object and what assumptions can be made to implement those methods). For Java implementation, I am also wondering how the corresponding Java object will be removed from the heap (e.g. when CORBA ORB releases the reference of that Java object?).};

A process subscribes to alarms via a method that is part of all RO (read-only) properties. Following is the code from the ROdouble property; for other types all occurrences of double have to be replaced correspondingly:

Subscription new_subscription_Alarm(in Alarmdouble cb, in CBDescIn desc);

Only properties of type RO have alarms, as RW properties should not even be able to set values in the alarm ranges. The method returns a Subscription object, which has to be used to destroy the subscription to the alarm events. The Subscription object is the event source interface. It is also the superclass for monitors (see next section).

interface Subscription{

    // temporarily suspends dissemination of event callbacks.
    void suspend();

    // resumes dissemination of callbacks. Ignored if no previous suspend occured.
    void resume();

    // stops dissemination of event callbacks and releases all resources.
    void destroy();
}; 

A very important feature of alarms is that an alarm event is sent immediately after the client has subscribed to the alarm and when a server reconnects to existing client subscriptions after a restart. The event is used to notify the client of the current alarm status. If everything is OK, the alarm_cleared() method is called, otherwise the alarm_raised() method returns the code for the current alarm. The reason for this requirement is that when a client subscribes freshly to an alarm, it does not know, whether the property is in normal or alarm state. As alarm events are sent only upon changes of alarm conditions, the client might never know that the property has already raised an alarm and that further operations on the property or its device should be restricted.

This requirement is particularly useful in two cases:

...