[omniORB] resolve() and _remote_non_existent()
smitha smi
smithatv at gmail.com
Mon Jan 21 16:10:45 GMT 2013
Hi,
Thanks for the info.
Below are few more concerns.
(1)
What exactly is the difference between
_remote_non_existent and _non_existent ?
(2)
We have been using : _remote_non_existent: from past many years and only
now we are seeing the issue.
In there any possibility that, _remote_non_existent will throw an exception
and _non_existent will return false?
(3)
As it involves lot of testing and jestification we need to give for
replacing _remote_non_existent() with _non_existent() we need to prove
that (2) is there any way i can recreate an issue suce that
"_remote_non_existent() " will throw an exception and _non_existent()
will return false.?
Please help us in this regard.
Thanks,
Smitha
On Fri, Dec 21, 2012 at 7:52 PM, Duncan Grisby <duncan at grisby.org> wrote:
> On Wed, 2012-12-12 at 18:50 +0530, smitha smi wrote:
>
> > Below is the sequence of calls i make.
> >
> > (1) o_ObjRef = rootContext->resolve(name);
> >
> > This call is success as it is not throwing any exception.
>
> That call talks to omniNames and resolves the name to an object
> reference. omniNames doesn't know or care whether the object reference
> is valid.
>
> > try {
> >
> > ServerReady_var l_readyObjRef = ServerReady::_narrow(o_ObjRef);
>
> That uses static knowledge to compare the expected interface with the
> interface details stored in the object reference. In this case, it does
> not need to do a remote call.
>
> > // Note: _is_nil call does not result in IPC
> >
> > if (l_readyObjRef->_is_nil())
>
> _is_nil() never does a remote call. It is comparing the object reference
> to nil, which is a purely local operation. An object reference is only
> nil if it is nil. It has nothing to do with whether the object exists or
> not.
>
> [...]
> > if(l_readyObjRef->_remote_non_existent())
>
> You shouldn't call _remote_non_existent -- that is an internal omniORB
> implementation detail. You should call _non_existent, which is the
> standard method.
>
> [...]
> > catch (...)
> > {
> > printf("\n _remote_non_existent() threw an exception\n");
> > }
>
> [...]
> > Result of execution of this code is : "_remote_non_existent() threw an
> > exception"
>
> If you catch CORBA::SystemException, you'll be able to call _name() on
> it and you'll see what the exception was.
>
> _non_existent contacts the server and asks if the object exists. It can
> throw system exceptions like CORBA::TRANSIENT or CORBA::COMM_FAILURE if
> the server cannot be contacted. If the server can be contacted but the
> object does not exist, _non_existent will return true. omniORB's
> internal _remote_non_existent will throw CORBA::OBJECT_NOT_EXIST.
>
>
> > (a) What is the difference between resolve() and
> > _remote_non_existent() ?
>
> They are totally unrelated. resolve() is an operation on the naming
> service that looks up a name. _non_existent is about checking the
> existence of an object.
>
> > (b) After successfully getting the object reference by calling
> > resolve() , why show we make call to remote_non_existent() ?
>
> You shouldn't call _remote_non_existent! You could choose to call
> _non_existent if you want to make an initial check for object existence.
>
> [...]
> > If Object was not existing, then resolve() it self should have thrown
> > exception. but , it did not throw any exception Why?
>
> resolve() looks up an object in the naming service. The naming service
> doesn't care at all whether the object references it contains are valid
> or not.
>
> Regards,
>
> Duncan.
>
> --
> -- Duncan Grisby --
> -- duncan at grisby.org --
> -- http://www.grisby.org --
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.omniorb-support.com/pipermail/omniorb-list/attachments/20130121/9dde8821/attachment.html>
More information about the omniORB-list
mailing list