[omniORB] 3 questions about CORBA, IIOP, and omniORB

[Duncan Grisby]

On Wednesday 17 December, "Thomas Zumbiehl" wrote:

> I can sometimes see some strange behavior in my server, compiled with omniORB
> 4.0.7 :
> I send 50 identical requests to my server, sometimes 2 fail.

What exactly do you see at the application level when they fail?

> When it fails, I can see these (abnormal, to my application point of view)
> omniORB traces :
> 2008/12/17 11-14-32 : omniORB: (38)
> 4749 4f50 0102 0100 a400 0000 1306 0000 GIOP............
> 0300 0000 0000 0000 1700 0000 ff62 6964 .............bid
> 6972 706f 61fe 3ccc 4849 0100 1bb9 0000 irpoa.<.HI......
> 0000 a750 1000 0000 6765 7453 656c 6563 ...P....getSelec
> 7452 6573 756c 7400 0000 0000 0000 0000 tResult.........
> 1200 0000 4167 656e 7449 436c 6553 6572 ....AgentICleSer
> 7669 6365 7300 0001 0100 0000 1b00 0000 vices...........
> 4943 6c65 4e61 6d65 2c53 6572 7669 6365 ICleName,Service
> 5479 7065 2c4c 6162 656c 0039 1400 0000 Type,Label.9....
> 5365 7276 6963 654e 616d 653d 5243 3832 ServiceName=RC82
> 5048 4100 0100 0000 0031 3839 0000 0000 PHA......189....
> 2008/12/17 11-14-32 : omniORB: (38) Dispatching remote call 'getSelectResult'
> to: root/bidirpoa<167> (active)

This is a normal incoming request call.

> ...
> 2008/12/17 11-14-32 : omniORB: (38) omniRemoteIdentity deleted.
> 2008/12/17 11-14-32 : omniORB: (38) ObjRef(IDL:corbacom/
> LogServiceInterface:1.0) -- deleted.

This means that an object reference was deleted. Whether that's right or
wrong depends on what your application is doing with object references.
The omniRemoteIdentity is an internal part of the object reference that
has been deleted.

> ...
> 2008/12/17 11-14-32 : omniORB: (38) sendChunk: to giop:tcp:10.151.35.219:41645
> 28 bytes
> 2008/12/17 11-14-32 : omniORB: (38)
> 4749 4f50 0102 0101 1000 0000 1306 0000 GIOP............
> 0000 0000 0000 0000 0000 0000           ............

That's a reply message. It looks normal.

> That bring my global system wrong.

In what way?  There's nothing unusual looking about those traces.

> So, first question : I there any kind of way omniORB could delete an
> omniRemoteIdentity where it should not, or is it possible that it is
> displaying wrong information ?
>
> The fact is that the same sequence occurs at both one of the two
> failures. And omniORB says, two times, that the omniRemoteIdentity is
> deleted, while there should be only one holded (set earlier in the
> application) ?

The omniRemoteIdentity is deleted when the object reference it is inside
is deleted. Only you can tell us if you're expecting an object reference
to be deleted at that stage. If you're not expecting one to be deleted,
you have your reference counting wrong.

> Second question : What is the meaning of the 28 bytes chunk sent ? It seems to
> be understood as a reply to the getSelectResult() request...

It is indeed a reply to the getSelectResult call.

> Third question : My server needs to hold interfaces for a while

"Interfaces" are not things you can hold. You probably mean servants
that incarnate particular objects, which have particular interfaces.

>  , but those need to be deactivated while they are not used (I use a
> close() request to tell an interface that it can be destroyed). How
> should I handle the servant activation/deactivation ?

> For now, I use the POA's activate_object() and deactivate_object() methods,
> but I am now thinking I can be wrong.

Those are the right methods to use.

You should read "Advanced CORBA Programming with C++" to learn all about
the correct terminology and object lifecycles and so on.

Cheers,

Duncan.

-- 
 -- Duncan Grisby         --
  -- duncan at grisby.org     --
   -- http://www.grisby.org --