Free High Performance CORBA Notification Service from AT&T Laboratories

omniORB Home AT&T Research

omniNotify 2.1 Release Notes...

This is a bug-fix release. It fixes two cases where I added default clauses to switch statements to get rid of compiler warnings.

omniNotify 2.0 Release Notes...

The most significant change from omniNotify 1.2 to 2.0 is that omniNotify 2.0 works with omniORB 4.   Many thanks to Duncan Grisby for adding stand-alone autoconf support and also for getting things working on Windows!

For Windows, omniORB4 version 4.0.2 or later  is a requirement (and you are strongly urged to use the very latest available omniORB 4 release).   For other operating systems, it is probably still possible to using omniNotify 2.0 on top of omniORB3,  however I am not going to attempt to keep omniNotify working with omniORB3 in the future, so you are also strongly urged to start using omniORB4!

omniNotify 2.0 adds a number of new administrative features, such as 'object garbage collection' of dead filter, channel, admin and proxy objects.  See the channel.cfg file (or standard.cfg) for the params that control garbage collection.  Also see the new OutgoingTimeout and IncomingTimeout params in the config file.  Garbage collection and new timeout params are also discussed here.

A number of bugs have been fixed, the most important being a couple of deadlock cases as well as a case where an event lock was held across a push call.  Internal outgoing event queues for proxies are now cleared properly in all cases where the proxy is no longer in use.  Removed the constraint on type and domain names which were formerly restricted to alphanum and underscore -- spec does not have this restriction. 

One key difference between building against omniORB3 vs. omniORB4 is the treatment of TimeBase::TimeT type as found in <TOP>/idl/COS/TimeBase.idl, which can either be a struct with 'low' and 'high' fields, or a CORBA::ULongLong, depending on the NOLONGLONG flag:

#ifdef NOLONGLONG
        struct ulonglong{
                unsigned long           low;
                unsigned long           high;
        };
        typedef ulonglong               TimeT;
#else
        typedef unsigned long long      TimeT;
#endif

omniORB3 standard builds use the NOLONGLONG flag, while omniORB4 standard builds do not. This is done because omniORB4 has full support for CORBA::ULongLong's passed in ANY values, whereas omniORB3 does not. This affects the type in <TOP>/include/COS/TimeBase.hh and the stubs/skels in the libCOS4 library that is built when omniORB4 is built.

omniNotify 2.x code assumes that it should use the struct form when used with omniORB3, and the CORBA::ULongLong form when used with omniORB4.

omniNotify 1.2 Release Notes...

Release 1.2 depends on omniORB version 3.0.4. It does not work with omniORB 4.x. omniNotify release 2.0 and later will work with omniORB 4.x.

Platform and supported features: see the 1.1 Release Notes below.

Added Some Extra Functionality

1. There is a new ndadmin program in the examples directory. It supports the same Interactive Mode supported by notifd via the -i option. Thus, you can now start notifd without -i, and at any time start up an ndadmin to interactively control it. Note that 'exit' no longer destroys the server, it simply exits the Interactive Mode. To destroy the server, use 'shutdown'.

2. A new delay param, -M, was added to all the examples. Use -h with any of the example programs for info.

Fixed All Known 1.1 Bugs

See the Old 1.1 Bug List for the list.

omniNotify 1.1 Release Notes...

This release depends on omniORB version 3.0.4.  It should also work with omniORB 4.0.x, however it is being released before omniORB 4.0 is finalized, so no guarantees.  

These release notes contain:

1. What platforms does omniNotify compiles on?
2. What parts of the CosNotification spec are not yet implemented?
3. What changed since the omniNotify 1.0 release?

(1) What platforms does omniNotify compile on?

It should be possible to build omniNotify on most of the platforms on which one can build the omniORB libraries. So far, we have successfully built omniNotify on:

• Linux 2.x (x86)/egcs-1.1.2/binutils-2.9.1.0.14/GNU Libc version 2
• Solaris 2.{5,6}/ Sun SparcCompiler C++ version 4.2
• SGI Irix 6.x/SGI C++ compiler 7.2

Porting to Windows NT/2000 is on our list of things to do. 

(2) What parts of the CosNotification spec are not yet implemented?

We plan to implement the entire spec, except perhaps for the CosTypedNotify* interfaces. (We would like feedback on why/whether we should implement the typed channel interfaces.)

For omniNotify 1.1., in addition to lacking CosTypedNotify* support, these things are not yet implemented:

• The channel does not support Persistent Events or Persistent Connections.
• The channel does not support Mapping filters.
• There is only partial wildcard support; see 1.0 release notes.

(3) What changed since the omniNotify 1.0 release?

Added new features

• Added support for non-zero PacingInterval.
• Added support for OrderPolicy and DiscardPolicy.
• Added new logging facility, with separate debug and report logs, and flags controlling what is logged to each.  See the flags in channel.cfg.  
• Added new idl, AttNotification.idl, with interfaces for each major entity managed by omniNotify (server, channel factory, filter factory, channels, admins, and proxies).   You can narrow a CosNotif* reference to get an AttNotification reference and use it to obtain additional non-standard functionality, described in the following items.  The idl file sits in an idl subdir of omniNotify tree, rather than at omniORB root idl, to allow us to update omniNotify idl without having to coordinate with omniORB releases.  A new library for AttNotification stubs and skeletons has been added as well.  The server links against this library as well as the omniORB-level COS library.
• Added server-level configuration properties, called ServerQoS properties.  Moved a number of the AdminQoS properties to be ServerQoS properties (the ones that can only be set at the server level, i.e., ones that cannot have different settings for different channels).  AttNotification::Server supports get_server_props and set_server_props.
• AttNotification::ChannelFactory supports the QoSAdmin (set_qos) and AdminPropertiesAdmin (set_admin) interfaces, allowing one to get/set theNotifQoS and AdminQoS properties that are used as *defaults* by the channel factory for construction of new channels.  
• Added new AttNotification::Interactive interface, available interactively via the -i option of notifd and programmatically (all AttNotification entities support this interface).  Use 'help' for details.

Extended and completely rewrote the examples.

• The examples now use POA stubs and skeletons (the 1.0 examples are BOA-based examples).

• The client code used in the examples is more "real" (more robust, more options, ...). All 16 kinds of channel clients are now represented, and a common code base is used, making it much easier to consistently modify all the examples.  Since the beta release, the clients now clean up after themselves better as well: the admins, proxies, and filters that they constructed at the channel are now destroyed on exit.
  
  The advantage of this approach is that the examples should be a good starting point for writing real client applications. The disadvatage is that these examples can be hard for a novice programmer to read. (We added a file READING_THE_CODE which should help some.)

Library code improvements

• Removed static array bounds limit on thread stats array.  Similar/related: changed to using global hash table to assign one RVM per thread that does filter evaluation.
• Replaced unix-specific time-related stuff with RDITimeWrappers module.  Because we are avoiding using unix calls, local clock accuracy and time zone info are currently set "by hand" as ServerQoS params.
• Eliminated some code duplication across the 16 kinds of proxy classes implemented by the channel.
• One side-effect of new logging module is no longer including <iostream.h> in any of our .h files.  (However, it is getting included by the flex-generated C++ scanner.  It would be great to get rid of this final use of iostream.)

Fixed all known 1.0 bugs:

• Fixed Bug # 1 : A small scoping error caused a null IOR to be installed in the name service. FIXED.
• Fixed Bug # 2 : Changed architecture of channel so that offer_change and subscription_change messages are sent by threads in special thread pools rather than by the thread running the client request which triggered the change message. Added ServerQoS properties for controlling how many threads are in each pool -- see channel.cfg for details.
• Fixed an unreported bug (channel was incorrectly holding a proxy's operation lock across try_pull outcalls).

Fixed all other known (post-1.0?) bugs:

• [Reported by ...] When a proxy connected to an external supplier is disconnected/destroyed or enters an exceptional state, the set of types it had offered via offer_change was not properly retracted. FIXED.
•  [Reported by Janet Tvedt] Destruction of a ConsumerAdmin or SupplierAdmin did not properly handle cleanup of proxy information in certain omniNotify internal data structures. Resulted in core dump in some cases, while in
  other cases a consumer continued to get notifications even after its admin had been destroyed. FIXED.
• [Caught by internal testing.] Fixed some errors in channel shutdown sequence which, in rare cases, resulted in a deadlock. FIXED.
• [Caught by internal testing.] Evaluation of supply-side filters for CORBA::Any events had not been implemented. Also, stats (match and eval counts) were not tracked properly for supply side filtering. FIXED.
• [Caught by internal testing.] The default channel (channel zero) was correctly initialized (from config file, env variables, command line args) but all other channels were created based only on the built-in defaults. FIXED.

omniNotify 1.0 Release Notes...

The current release is omniNotify 1.0 (the initial release). This release depends on omniORB version 3.0.2

Important: The implementation currently uses BOA stubs. We plan to switch to using POA stubs in the near future. If you are considering modifying the omniNotify library or daemon, please contact us first since you are much better off doing developing against the POA code.

Although the current examples are also written using BOA stubs, there are no constraints on what kinds of clients you write. If you write POA-based clients you should include "COS/CosNotification.hh" (and related .hh files) and link against libCOS3. If you write BOA-based clients you should include "COS/BOA/CosNotification.hh" (and related .hh files) and link against libCOSBOA3.

It should be possible to build omniNotify on most of the platforms on which one can build the omniORB libraries. So far, we have successfully built omniNotify on:

• Linux 2.x (x86)/egcs-1.1.2/binutils-2.9.1.0.14/GNU Libc version 2
• Solaris 2.{5,6}/ Sun SparcCompiler C++ version 4.2
• SGI Irix 6.x/SGI C++ compiler 7.2
• HP-UP 11.0 / aCC

omniNotify is not yet a complete implementation of the CORBA Notification Service specification. The following features are not supported in the current release.

• Mapping filters
• Order and Discard QoS properties
• PacingInterval QoS property (only a PacingInterval of  zero is supported at the moment)
• Persistent Events and State

In addition, at present there is only partial wildcard support. In general, an event type has two parts, a domain name and type name, written D::T. omniNotify supports a wildcard for the entire domain name and/or type name, but not as a part of a name that contains some character literals. In other words, "*::*", "*::T", "D::*", and "D::T" forms are supported, where D and T are string literals, but an event type such as foo*::bar*zot is not yet supported.

We are in the process of  implementing all of the above features.   Support for PacingInterval has top priority and should be available very soon.

Conformance Testing Notes

DSTC has a publicly available conformance test suite for CosNotification services, available as part of a demo download of dCon, a java-based CosNotification service. omniNotify passes all of the test cases in the test suite released with dCon version 2.2. However, we had to fix a bug in 2 of the test cases. EventChannelTest6 and EventChannelTest7 are supposed to test the use of the MaxConsumers and MaxSuppliers QoS properties. One test is supposed to set MaxConsumers to 1 and then try to connect more than 1 consumer, while the other is supposed to set MaxSuppliers to 1 and then try to connect more than 1 supplier. The bug is that the test which sets MaxConsumers tries to connect 2 suppliers while the test which sets MaxSuppliers tries to connect 2 consumers. Switching the use of MaxConsumers/MaxSuppliers in the 2 tests gives you correct versions of these test cases.