[omniORB] Problems with omniEvent

[BETIS Alexandre]

Hi, thanks for the answer!

<snip>

>   The direction i intend to move omniEvents is towards
> small memory footprint and high performance rather than
> features, as i believe, that to be the core functionality
> of the EventService. If one want features, surely one would
> choose the NotificationService instead.
> You are of course quite welcome to hack around in omniEvents
> to solve your immeadiate problems etc. I would very
> much like to hear peoples opinion about requirements not
> specified by the standard etc. Things i am wondering about
> are typed events, is anyone at all using those? How often
> do people create and destroy event channels? How often do
> people need a persistent event service? Performance requirements
> in terms of the number of events pushed a second would be
> nice too. One requirement already high on the list is
> enabling the use of SSLIOP.

Ok, here is my Christmas wish list:
 + Control of event queues length (done in the current implementation)
 + One thread per client (done in the current implementation).
 + Possibility to disable/enable the persistence mechanism (todo)
 + Rigorous memory management. In particular, when a push client dies, 
   kill his event queue after an adequate delay (todo)

<rant>
I think it is quite a reasonable wish list, but most implementations seem
not to think so. Frankly, an event channel with no buffer limit is 
as useful as a bucket of water with a gaping hole at the bottom! Another
silliness I have noticed are those event channels that consciously shoot
the ordering of events in mid-air by spawning more than one thread by
client. Bah.
</rant>

I don't think controlling the push frequency is a good idea. Controlling
the event queues length is sufficient. Clients should check if they are
fast enough by checking if they haven't lost an event. This means
that you must number the events, but this is also an issue that is not
relevant for the event channel.

I am not sure I understand what you call 'typed' events? 

Anyway, I would advise keeping much of the code actually used. It is
really nice. We have an automated test bed for event channels here, and
this event channel ranks #1 among those we have tested so far.

Cheers,

-- Alex