[omniNotify] performance questions

[Robert E. Gruber]

> From the documentation it appears that omniNotify does honor priority and 
> timeout values for events that it receives.  Is this true?

Yes, omniNotify supports OrderPolicy and DiscardPolicy, and the
settings of PriorityOrder and DeadlineOrder are used to indicate
control based on Priority or Timeout values, respectively.
omniNotify applies these policies at the level of individual
consumer queues; it does not support a DiscardPolicy based on
Priority or Timeout at the global incoming event queue.

OrderPolicy is only relevant if the channel has more than
one event queued up for a given consumer.  This happens
for both push and pull batch consumers, and also for 
single-event pull consumers.  For
single-event push consumers, the queue size is normally
1 or 0 because events are pushed out of the queue
immediately after they are added, so OrderPolicy does
not have any effect.  

DiscardPolicy is only relevant if MaxEventsPerConsumer is
set to positive value K, and K+1 events have been queued up
for a given consumer.   In this case, DiscardPolicy
controls which of the K+1 events is discarded to return
the queue size to K.

> Also, is there an easy way to support a "pull event period" of "on demand"?
> I have not tried using pull functionality with omniNotify because it was 
> distastrous with the event service implementations I tried.  In some cases 
> (well, in my world anyway) a pull consumer may require an update once or
> twice in its lifetime, so continuous polling is overkill.  Any ideas?

I'm not sure what you are asking for.  PullEventPeriod applies to
pull suppliers, and it is a millisecond-based control.
Are you saying that instead of, say, pulling every
100 milliseconds, an "on-demand" pull supplier would only be polled
by the channel if a pull-style consumer did a pull or try_pull call?

One way to implement something like this
without changing omniNotify is to use push
suppliers/consumers and to have an extra event type that is used to
request an event push.  E.g., have event type SomeDomain::Foo
for foo events, and use SomeDomain::NeedFoo to signal that 
a Foo event is needed.  A push consumer could register for Foo
events, and could push a NeedFoo event to the channel when it needs
a Foo event.  A push supplier could register as a consumer of NeedFoo
events, and for each one it receives, it would push a Foo event
to the channel.

If I did not understand what you need, please send more details.

-- Bob

-----Original Message-----
From: omninotify-list-admin@realvnc.com
[mailto:omninotify-list-admin@realvnc.com]On Behalf Of Janet Tvedt
Sent: Monday, July 15, 2002 3:54 PM
To: omninotify-list@realvnc.com
Subject: [omniNotify] performance questions



>From the documentation it appears that omniNotify does honor priority and 
timeout values for events that it receives.  Is this true?

Also, is there an easy way to support a "pull event period" of "on demand"?
I have not tried using pull functionality with omniNotify because it was 
distastrous with the event service implementations I tried.  In some cases 
(well, in my world anyway) a pull consumer may require an update once or
twice in its lifetime, so continuous polling is overkill.  Any ideas?

Thanks!

Janet

--------------------------------------------------------------------------
Janet Tvedt, National Solar Observatory/SOLIS   Email: tvedt@noao.edu
P.O. Box 26732, Tucson, AZ  85732-6732          Phone: (520) 318-8388
950 N. Cherry Ave., Tucson, AZ  85719           FAX:   (520) 318-8278

_______________________________________________
omninotify-list mailing list
omninotify-list@realvnc.com
http://www.realvnc.com/mailman/listinfo/omninotify-list