This chapter explains the allowed properties for CosNotification_QoSAdmin and CosNotification_AdminPropertiesAdmin.
The cosNotification application supports the following QoS settings:
QoS | Range | Default |
EventReliability | BestEffort/Persistent | BestEffort |
ConnectionReliability | BestEffort/Persistent | BestEffort |
Priority | +/-32767 | 0 |
OrderPolicy | Any-, Fifo-, Priority- and Deadline-Order | PriorityOrder |
DiscardPolicy | RejectNewEvents, Any-, Fifo-, Lifo-, Priority- and Deadline-Order | RejectNewEvents |
MaximumBatchSize | long() > 0 | 1 |
PacingInterval | TimeBase::TimeT (see cosTime) | 0 |
StartTimeSupported | boolean | false |
StopTimeSupported | boolean | false |
MaxEventsPerConsumer | long() > 0 | 100 |
Timeout | TimeBase::TimeT (see cosTime) | No timeout |
Comments on the table 'Supported QoS Settings':
max_events
,
interval_events
and timeout_events
determine
the behavior of this setting.
ok
to its associated Proxy, the Proxy will discard
all events and terminate. Using Persistent and anything other than ok
is returned, events will be dropped but the proxy will retry later when
next delivery is due. A child may not have Persistent while its parent
has BestEffort QoS set, e.g., Proxy vs. Admin. If OBJECT_NOT_EXIST
,
NO_PERMISSION
or CosEventComm_Disconnected
is thrown,
the associated object will terminate even if this parameter is
set to Persistent.
StartTime
(TimeBase::UtcT - absolute time) will not be delivered until the
StartTime value have been exceeded. See also the cosTime
application.
StopTime
(TimeBase::UtcT - absolute time) or Timeout
(TimeBase::TimeT -
relative time) will be discarded if the object has not been able to
deliver the event in time. See also the cosTime
application.
StopTimeSupported
equals true, this setting will be applied
if events cannot be delivered within its time limit.
![]() |
Several of the above QoS Properties can be changed during run-time but we strongly advice
not to since, if a relatively large amount of events are waiting for delivery, some of the
QoS settings would require a total reorder of the events. The QoS property |
Assume we have a Consumer Admin object which we want to change the current Quality of Service. Typical usage:
QoSPersistent = [#'CosNotification_Property' {name='CosNotification':'ConnectionReliability'(), value=any:create(orber_tc:short(), 'CosNotification':'Persistent'())}], 'CosNotification_QoSAdmin':set_qos(Ch, QoSPersistent),
If it is not possible to set the requested QoS the UnsupportedQoS
exception is raised, which inlcudes a sequence of PropertyError
's
describing which QoS, possible range and why is not allowed. The error
codes are:
The CosNotification_QoSAdmin interface also supports an operation
called validate_qos/2
. The purpose of this operations is to check
if a QoS setting is supported by the target object and if so, the operation
returns additional properties which could be optionally added as well.
The cosNotification application supports the following Admin Properties:
Property | Range | Default |
MaxQueueLength | 0 | 0 |
MaxConsumers | long() >= 0 | 0 |
MaxSuppliers | long() >= 0 | 0 |
According to the OMG specification the default values for Admin Properties
is supposed to be 0
, which means that no limit applies to these
properties.
![]() |
Admin Properties can only be set on a Channel Object level, i.e.,
they will not have an impact on any Admin or Proxy Objects. Currently,
setting the Admin Property |