[omniNotify] Using omniNotify without creating endpoints

[Bob Gruber]

No, I don't, sorry.  

You could ask Duncan if you compile omniORB with -g, what function
should you set a breakpoint on so that you can figure out where the
endpoint creation is occurring.

-- Bob
 


On Tue, 25 May 2004 13:33:03 -0600, Mark Zimmerman <markzimm at frii.com> wrote:
> 
> Yes, I just meant the COS library. Do you have any idea what might be
> creating this (these) endpoint(s) and why?
> 
> 
> On Tue, May 25, 2004 at 01:03:50PM -0400, Bob Gruber wrote:
> > If this is a client, you should not link against the omniNotify
> > library, just the COS library.   Or did you mean the COS library?
> >
> > On Fri, 21 May 2004 09:24:25 -0600, Mark Zimmerman <markzimm at frii.com> wrote:
> > >
> > > On Tue, May 18, 2004 at 03:54:55PM +0100, Duncan Grisby wrote:
> > > > On Friday 14 May, Mark Zimmerman wrote:
> > > >
> > > > > I have a small program that does nothing but post a single message to
> > > > > the omniNotify notification channel (from a push_supplier) and exit.
> > > > > It works fine with a default configuration but I am trying to
> > > > > understand why it insists on creating and serving incoming endpoints.
> > > > > Unless I misunderstand the meaning of an incoming endpoint, it seems
> > > > > to me that it doesn't need one.
> > > > >
> > > > > However, when I include 'endPointNoListen = giop:tcp::' in the
> > > > > configuration, it fails:
> > > >
> > > > That doesn't do what you think it does. endPointNoListen asks the ORB
> > > > to publish the given endpoint in IORs, without listening on it. For
> > > > that to work, you have to give the full details of the endpoint, since
> > > > there is no real endpoint to get the details from. Anyway, it's not a
> > > > way to stop your program from listening.
> > > >
> > > > [...]
> > > > > With endPointNoListen excluded, the program works but the endpoints
> > > > > are never used (I think). I have set 'serverTransportRule = * none'
> > > > > which, I believe, will prevent them from accepting connections.
> > > > >
> > > > > Is there something in omniNotify that requires endpoint creation in
> > > > > this context? Is there a way to avoid this?
> > > >
> > > > The incoming endpoints are initialised when you resolve the root POA
> > > > (or get a reference to the BOA). If the code doesn't every get hold of
> > > > the POA, the endpoints are not initialised. Something in your code, or
> > > > a library you are using (are you linking with omniNotify?) must be
> > > > resolving the root POA.
> > > >
> > >
> > > I guess it must be the omniNotify library. The only reference to the POA
> > > in my test case was in the destructor. I had forgotten why it was there
> > > so I commented it out (see below) and tried again. I got the error shown
> > > at the bottom of the trace log (see farther below) since the library
> > > apparently resolved the POA and I was now failing to deactivate it.
> > >
> > > I am now uncertain as to whether I can make omniNotify not resolve the
> > > root POA when all I want to do is post a message.
> > >
> > > //   try {
> > > //      PortableServer::POA_ptr poa = RefUtils::POA();
> > > //      PortableServer::Servant serv = poa->reference_to_servant(_this());
> > > //      PortableServer::ObjectId_var oid = poa->servant_to_id(serv);
> > > //      poa->deactivate_object(oid);
> > > //   }
> > > //   catch (...) {} // ignore any error during destroy call
> > >
> > > omniORB: Creating ref to remote: key<NameService>
> > > target id      : IDL:omg.org/CORBA/Object:1.0
> > > most derived id:
> > > omniORB: Initial reference `NameService' resolved from configuration file.
> > > omniORB: AsyncInvoker: thread id = 1 has started. Total threads = 1
> > > omniORB: Creating ref to remote: key<NameService>
> > > target id      : IDL:omg.org/CosNaming/NamingContext:1.0
> > > most derived id:
> > > omniORB: Creating ref to remote: root<4>
> > > target id      : IDL:omg.org/CORBA/Object:1.0
> > > most derived id: IDL:att.com/AttNotification/EventChannel:1.0
> > > omniORB: Creating ref to remote: root<4>
> > > target id      : IDL:omg.org/CosNotifyChannelAdmin/EventChannel:1.0
> > > most derived id: IDL:att.com/AttNotification/EventChannel:1.0
> > > omniORB: Creating ref to remote: root<27425>
> > > target id      : IDL:omg.org/CosNotifyChannelAdmin/SupplierAdmin:1.0
> > > most derived id: IDL:att.com/AttNotification/SupplierAdmin:1.0
> > > omniORB: Creating ref to remote: root<27426>
> > > target id      : IDL:omg.org/CosNotifyChannelAdmin/ProxyConsumer:1.0
> > > most derived id: IDL:att.com/AttNotification/StructuredProxyPushConsumer:1.0
> > > omniORB: Creating ref to remote: root<27426>
> > > target id      : IDL:omg.org/CosNotifyChannelAdmin/StructuredProxyPushConsumer:1.0
> > > most derived id: IDL:att.com/AttNotification/StructuredProxyPushConsumer:1.0
> > > omniORB: Initialising incoming endpoints.
> > > omniORB: Starting serving incoming endpoints.
> > > omniORB: Adding root<0> (activating) to object table.
> > > omniORB: Creating ref to local: root<0>
> > > target id      : IDL:omg.org/CosNotifyComm/StructuredPushSupplier:1.0
> > > most derived id: IDL:omg.org/CosNotifyComm/StructuredPushSupplier:1.0
> > > omniORB: AsyncInvoker: thread id = 2 has started. Total threads = 2
> > > omniORB: ERROR -- A servant has been deleted that is still activated.
> > >      id: root<0> (active)
> > >
> > >
> > >
> > >
> > > _______________________________________________
> > > omninotify-list mailing list
> > > omninotify-list at omniorb-support.com
> > > http://www.omniorb-support.com/mailman/listinfo/omninotify-list
> > >
>