[omniNotify] Multiple events received from one single post

[Janet Tvedt]

Joe,

I had this same problem with applications that use Visibroker for
Tornado.  I always thought it was a bug in Visibroker but couldn't get
them to fix it.  The Visibroker ORB would accept notifications for an
old instance of a servant.

To fix this, I did just what you suggested.  However, I had to change
omniNotify to get it to work.  The added functionality was suggested by
Bob Gruber but I implemented it in my own copy of omniNotify.  I've
attached the affected omniNotify files and the cleanup code.  I think
the function "destroyConsumerAdmins" does what you are looking for.
However, in my application I used StructuredEventPushConsumer and had a
new consumer admin for each structured push consumer.  Your application
is most likely different.

I'd be curious to know what ORB you are using and if anyone has a
cleaner solution to this problem.

Good luck!

Janet Tvedt
National Solar Observatory
tvedt at nso.edu 

On Thu, 2006-03-02 at 12:07 -0400, Joe Pimentel wrote:
> Hi,
> 
> In my app, sometimes when I push one single event into the channel my
> listenter receives more than one notifications.
> 
> My application has 3 daemons that receives and post events to the same
> channel. 
> In the begining i was not calling a cleanup method when these process
> goes down and I end up with this same behaviour. 
> Now I use to call the cleanup code on normal exit and usually things
> works fine. 
> But in some cases this behaviour comes again.  My bet is that when
> some daemon aborts the normal execution it leaves some dirty 
> elements active on the notify deamon. 
> Question: It is possible to have a  general cleanup code to execute
> before the daemons comes up ?
> 
> Thanks in advance for any clues ;-)
> 
> 
> -- 
> Joe Bertoli Pimentel
> joe.b.pimentel at gmail.com
> 
> _______________________________________________
> omninotify-list mailing list
> omninotify-list at omniorb-support.com
> http://www.omniorb-support.com/mailman/listinfo/omninotify-list
-------------- next part --------------
A non-text attachment was scrubbed...
Name: AttNotification.idl
Type: text/x-idl
Size: 10429 bytes
Desc: not available
Url : http://www.omniorb-support.com/pipermail/omninotify-list/attachments/20060302/5e161b41/AttNotification-0001.bin
-------------- next part --------------
A non-text attachment was scrubbed...
Name: CosNotifyChannelAdmin_i.h
Type: text/x-chdr
Size: 80943 bytes
Desc: not available
Url : http://www.omniorb-support.com/pipermail/omninotify-list/attachments/20060302/5e161b41/CosNotifyChannelAdmin_i-0001.bin
-------------- next part --------------
A non-text attachment was scrubbed...
Name: FreeOldEventConnections.cc
Type: text/x-c++src
Size: 21432 bytes
Desc: not available
Url : http://www.omniorb-support.com/pipermail/omninotify-list/attachments/20060302/5e161b41/FreeOldEventConnections-0001.bin
-------------- next part --------------
Installation Procedure for omniNotify
-------------------------------------

To install an upgrade to omniNotify, perform the following
steps:

1. Update the source by either a) or b) 

   
   a) Download tarball from 
         http://www.research.att.com/~ready/cgi-bin/nfycollect.cgi

      and extract source by:
	cd $CORBAHOME/src/services
	tar -xvf omniNotify<>.tar

   b) Update from CVS (use checkout if omniNotify directory does
      not exist)

           export CVSROOT=":pserver:anonymous at cvs.uk.research.att.com:/cvsroot"
           cvs login
           At the password prompt, enter the password cvs
           cd $CORBAHOME/src/services
           cvs update -r omniNotify1_develop omniNotify


2.  Edit omniNotify/idl/AttNotification.idl

    a.  Add two methods to the StructuredProxyPushSupplier interface:

   interface StructuredProxyPushSupplier : Interactive, CosNotifyChannelAdmin::StructuredProxyPushSupplier {
    CosNotifyComm::StructuredPushConsumer get_connected_consumer() raises (CosNotifyChannelAdmin::NotConnected);
    boolean is_connected();
   };


   b. Add two methods to the StructuredProxyPushConsumer interface:

   interface StructuredProxyPushConsumer : Interactive, CosNotifyChannelAdmin::StructuredProxyPushConsumer {
    CosNotifyComm::StructuredPushSupplier get_connected_supplier() raises (CosNotifyChannelAdmin::NotConnected);
    boolean is_connected();
   };


3.  Edit omniNotify/include/CosNotifyChannelAdmin_i.h


    a. Add the implementation of the two public methods to the StructuredProxyPushSupplier_i
       class declaration:

    class StructuredProxyPushSupplier_i : 
		public virtual RDIProxySupplier, 
		public virtual RDIProxyPushSupplier, 
		WRAPPED_SKELETON_SUPER(AttNotification, StructuredProxyPushSupplier) 
    {
      ...

      public:

        ...

        CosNC::StructuredPushConsumer_ptr get_connected_consumer( WRAPPED_DECLARG_VOID ) {
           return CosNC::StructuredPushConsumer::_duplicate(_consumer);
        };

        CORBA::Boolean is_connected( WRAPPED_DECLARG_VOID ) {
          return RDIProxySupplier::is_connected();
        };


      private:

        ...

    };


    b. Add the implementation of the two public methods to the StructuredProxyPushConsumer_i
       class declaration:

    class StructuredProxyPushConsumer_i : 
		public virtual RDIProxyConsumer,
		WRAPPED_SKELETON_SUPER(AttNotification, StructuredProxyPushConsumer) 
    {
      ...

      public:
    
        ...

	CosNC::StructuredPushSupplier_ptr get_connected_supplier( WRAPPED_DECLARG_VOID ) {
	  return CosNC::StructuredPushSupplier::_duplicate(_supplier);
	};

	CORBA::Boolean is_connected( WRAPPED_DECLARG_VOID ) {
	  return RDIProxyConsumer::is_connected();
	};

      private:

        ...
    };


4. Go to root directory of omniNotify installation and rebuild
   by typing the following:

   gmake veryclean
   gmake export



Notes:  
  In order for the Notification Service GUI to work properly,
the AttNotification interface had to be modified to include the
above methods.  These changes allow the tool to determine the
following:

  - host IP of each Comm.EventReceiver
  - TCP port number of each Comm.EventReceiver
  - connection status of each Comm.EventReceiver
  - connection status of each Comm.EventSupplier
  - server status of each Comm.EventReceiver
  - server status of each Comm.EventSupplier

  The connection status is true if the event channel is
connected to the receiver/supplier.  The server status 
is true if the Java ORB detects that the process that 
created the receiver/supplier is still running.