omniEvents (experimental POA version)

This is an EXPERIMENTAL port of omniEvents 2.4 to CORBA's Portable Object Adapter (POA). omniEvent's reliance on the old BOA architecture has been a serious impediment to developing further features. This release implements all of the basic Event Service features of omniEvents 2.4. Some of the Quality of Service features (max queue length, pullConsumer poll frequency) are hard-coded rather than configurable.

Download

omniEvents-poa-src.tar.gz (707791 bytes)

You can still browse the Autoconf macros

Features

This new version contains a number of significant enhancements over the previous one. I've individually designed each Proxy type for optimal performance, and minimal use of system resources. In particular, this implementation uses very few threads per channel, which helps to cut down on complexity and on locking overheads. It's been quite interesting. Although they seem superficially similar, I've found that the challenges are actually quite distinct.

• ProxyPushConsumer Implemented as a (mostly) stateless `DefaultServant'. The ProxyPushConsumer doesn't really care from whom messages are arriving, so I've used a single DefaultServant in a stateless POA to avoid expensive lookups in the active object map.
  Relies upon POA::Current to identify the source of disconnect messages. Sadly, POA::Current is only implemented in omniORB4.
• ProxyPullConsumer All outgoing calls are performed through the Dynamic Invokation Interface's (DII) send_deferred() method. This enables a single thread to manage communication with all connected suppliers, rather than having to use a thread per connection.
• ProxyPushSupplier Again, all outgoing calls are performed through the DII's send_deferred() method. A dedicated thread is used to maximize the output rate of events. Outgoing events are queued in a circular buffer that naturally discards the oldest messages if a Consumer can't keep up with the incoming event rate.
• ProxyPullSupplier The trickiest of the four, and the one where I've made the biggest compromise. try_pull() mode is straightforward, but pull() calls should really block until an event becomes available. I can't see a way of doing this without spawning and then blocking a thread for each incoming call. That's too expensive in threads for me, so I've made pull() calls time out immediately if there is no event waiting (they throw TRANSIENT).

In other news, all of these Proxy implementations are careful to send the proper disconnect message to their peers when they are disconnected. They also automatically disconnect when they receive an exception, which clears away server resources when misbehaved clients just disappear without letting us know they're going. This behaviour should probably be made a little more lenient when the exception is a TRANSIENT.

Doxygen code documentation is included in the download. I find it enormously helpful for finding my way round, so I thought I'd include it.

Contact

E-mail me: Alex Tingle <alex.omnievents(AT)firetree.net>