[Ace-users] Re: [tao-users] Event Service and Consumers/Suppliers with persistentIORs

Steve Totten totten_s at ociweb.com
Wed Aug 22 10:28:18 CDT 2007

Hi Markus,

Markus Debusmann wrote:

> Event Service and Consumers/Suppliers with persistent IORs

Which Event Service are you using?  TAO's Real-time Event Service
or TAO's implementation of the OMG CosEvent service?

Have you tried the Notification Service?  In particular, the
Notification Service supports the Connection Reliability QoS
property, which can be used in various recovery scenarios to
re-establish lost connections.

OCI's TAO Developer's Guide has a chapter on all of these
event services, including the Notification Service.

See also:


for an example of how various reconnection scenarios can work.

>>> I have a question concerning the use of the Event Service in 
>>> combination 
>>> with consumers/suppliers that use persistent IORs.
>>> My principal idea was to use consumers/supplier with 
>>> persistent IORs in 
>>> order to prevent a multiple registration of a 
>>> consumer/supplier crashed. 
>>> When restarted the reregistration results in a lot of exceptions when 
>>> the Event Service is trying to sent out consumers which not 
>>> valid anymore.
>>> Although the IORs of consumers/suppliers are persistent the Event 
>>> Service handles them as a registration of a new 
>>> consumers/suppliers. In 
>>> case of consumers, this results in receiving all events twice. This 
>>> proves to me that both IORs are still valid. But for some reason the 
>>> Event Service does not throw an 'AlreadyRegistered' exception when 
>>> reregistering after a crash.

I assume you mean 'AlreadyConnected'.  This exception should
be raised if a consumer tries to connect to a ProxyPushSupplier
and a consumer (the same or a different consumer) has already
connected once to that ProxyPushSupplier.  There are various
scenarios in both the Notification Service and TAO's RT Event
Service where reconnects are allowed.  See the Notify Service's
Reconnecting example above, for instance.  For the RT Event
Service to allow reconnects, the Event Channel must be created
with the appropriate consumer_reconnect or supplier_reconnect
attribute set to non-zero.

>>> I worked around this using transient IORs and letting the 
>>> Event Service 
>>> monitor broken links. This does very much the same except that the ES 
>>> needs one exception to notify that the llink is broken.

Right, you must be using the reactive consumer control strategy.

>>> I wonder why my approach using persistent IORs does not work.  Has 
>>> someone similar experience?

You raise an interesting issue.  Could you supply a simple test
case demonstrating the problem?

Steve Totten
  Steve Totten, Principal Software Engineer and Partner
  Object Computing, Inc. (OCI), St. Louis, MO, USA
  http://www.ociweb.com/  http://www.theaceorb.com/

More information about the Ace-users mailing list