[omniNotify] omniNotify cfg file (QoS values)

[Bob Gruber]

Frederic, you have asked a few questions recently, let me try to
answer all of them.

The first was about memory leaks, and another question was about
object GC config params.  As I think you may have figured out, the
omniNotify daemon (notifd) has a global event queue that it cleans up
based on configuration params.  So each additional event will cause
some small memory growth, until a GC time interval elapses, at which
point it is pruned.   You can control the event GC period with
QueueGCPeriod, and you can also set MaxQueueLength to a non-zero value
if you want to put an upper limit on the queue size.

In addition to event garbage collection (GC), there are also some
object GC configuration parameters that control how notifd attempts to
get rid of 'dead' objects, i.e., objects that appear to no longer be
in use.   Clients of the notification service cause the service to
construct various helper objects: channels, admin objects, proxy
objects, and filters, and these clients do not always properly clean
up after themselves, which can cause old helper objects to stay around
even after they are no longer used.  I think I have actually done
pretty good job describing the object GC params in the config file. 
If you have any specific questions about them, please send them to me
directly and I will try to clarify.

Your final question was about Timeout.  Timeout is used in conjunction
with the OrderPolicy and DiscardPolicy QoS params.  The former
controls how events are delivered, while the latter control which
event is discarded if the MaxQueueLength limit is hit and
RejectNewEvents is 1.  QoS properties can be set at the notifd,
channel, admin, proxy level.  A default Timeout value can be set as a
QoS property, while specific Timeouts can ALSO be set on a per-event
basis by including a Timeout value in each event.  If OrderPolicy is
set to DeadlineOrder, then events are 'sorted' for delivery using
(arrival_time + Timeout).  If OrderPolicy is set to AnyOrder or
FifoOrder, they are sorted by arrival time.  If set to PriorityOrder,
they are sorted by Priority.  Note that the timeout sorting is a
relative sort.   The notification spec includes a way to specify
absolute start and stop times for events, but omniNotify does not
support this, as indicated by the params StartTimeSupported and
StopTimeSupported which are both forced to be 0.  When specifying how
to do sorting for discard (DiscardPolicy), you can specify any of the
OrderPolicy policies above, and also LifoOrder.

Note that sorting policies only apply when multiple events destined
for a given consumer are queued at a channel.  If the channel 'keeps
up' with event arrivals such that it has already delivered the Kth
event before the (K+1)th event arrives at the channel, then sort
policy does not come into play -- events are delivered in arrival
order.  OrderPolicy only matters if the channel has to decide which
event to deliver next.

-- Bob Gruber