[omniNotify] Using omniNotify without creating endpoints
Bob Gruber
bob.gruber at gmail.com
Tue May 25 14:03:50 BST 2004
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
>
More information about the omninotify-list
mailing list