[omniORB] omniEvents 2.6.0 (All new stable release)

renny.koshy at rubixinfotech.com renny.koshy at rubixinfotech.com
Fri Oct 8 14:19:20 BST 2004


We had done quite a bit of testing of omniEvents vs. some commercial JMS 
solutions and found omniEvents to be far superior.  At that point, we 
started working with Alex (since early this year) on adding a lot of the 
'enterprise' class features of omniEvents.  We absolutely rely on 
federation, performance, etc.... Currently, one of our flagship products 
uses omniEvents extensively for a call-center solution.  This solution has 
a service level of 99.999% availability and we've been able to meet that, 
along with the intensive performance objectives.

In the production environment, we're using omniEvents running at about 
50-74 msgs per second (which isn't that big by todays large systems). This 
system has been running reliably since mid August ... it draws < 5% CPU on 
a Sun V480 w/ 2 x 1.2 GHz CPU's. 

I hope this helped.

Renny Koshy
President & CEO

RUBIX Information Technologies, Inc.

Janet Tvedt <tvedt at noao.edu>
Sent by: omniorb-list-bounces at omniorb-support.com
10/08/2004 12:41 PM
Please respond to tvedt

        To:     Alex Tingle <alex.omniorb at firetree.net>
        cc:     omniORB <omniorb-list at omniorb-support.com>
        Subject:        Re: [omniORB] omniEvents 2.6.0 (All new stable release)

Has anyone done any performance testing with this new version?

Janet Tvedt
National Solar Observatory

On Fri, 2004-10-08 at 08:56, Alex Tingle wrote:
> website: http://omnievents.sf.net/
> I am proud to announce omniEvents 2.6.0, the culmination of nearly a
> year's development and testing.
> omniEvents 2.6.0 is an almost entirely new implementation of the OMG 
> Event Service Specification v1.1 for omniORB. It builds upon the
> foundation of omniEvents v2.4.
> This new version contains a number of significant enhancements:
>  o Each Proxy type is individually designed for optimal performance,
>    and minimal use of system resources.
>  o Implements a sub-set of the Fault-Tolerant CORBA specification.
>    Servers may be configured to operate in pairs - if one fails then
>    clients automatically switch over to the alternate.
>  o Event channels can be federated, which allows multiple servers to
>    share the load of delivering events to many clients across a wide
>    area network.
>  o Event channels can be configured to only pass on events of a
>    particular CORBA type. Combined with channel federation, this
>    allows Consumers to choose which type of events to receive.
>  o The server runs as a daemon on Unix or a service on Windows. A
>    SysV style init file can be automatically installed on Unix, to
>    get you up and running with minimum fuss.
>  o omniEvents is now much better documented. There are detailed
>    installation instructions, full code documentation and even a
>    tutorial on writing an Event Service client.
>  o Implements OMG Event Service Specification v1.1 - with the correct
>    disconnection semantics. This makes it much easier to write
>    clients that can disconnect cleanly.
> Full documentation is here:
>  http://omnievents.sf.net/doc/index.html
> WARNING: This release is NOT backwards compatible. If you are
> upgrading from 2.4.1 or earlier, then remove your current
> installation before installing the new version.
> -Alex Tingle

omniORB-list mailing list
omniORB-list at omniorb-support.com

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.omniorb-support.com/pipermail/omniorb-list/attachments/20041008/2a405cba/attachment.htm

More information about the omniORB-list mailing list