[omniORB] problem with bidirectional feature

Fernando A. de Araujo Filho maverick@elogica.com.br
Thu Dec 5 03:25:02 2002


Hello,

Some days ago I posted a message about a problem with bidirectional feature
using OmniOrb4.
Maybe I am doing something wrong ...
basically:
If ONLY the client have the ORB parameter { "offerBiDirectionalGIOP", "1" },
and the server have the ORB parameter { "acceptBiDirectionalGIOP", "0" },
when the client narrow a reference to the server for the first time,
everything works
fine. The client pass a callback reference to the server (register itself on
server), and both sides
can invoke calls without any problem, not in bidirectional mode
(the same problem I have in bidirectional mode).
If  we stop the server, after restart it, when the client try to "connect",
alias, invoke a call to the server,
the exception below allways occurs.
omniORB: LocateRequest to remote: root<0>
...
omniORB: throw TRANSIENT from giopRope.cc:321 (NO,TRANSIENT_CallTimedout)

If  ONLY the ORB parameter offerBiDirectionalGIOP is equal to 0, on client
side, the problem not occurs.
The server and the client can die and restarts without any TRANSIENT
exception.
I am in troubles, because I cannot see what I am doing wrong. Bidirectional
feature is imperative to me.

I made modifications on bidir sample to get the same "behavior". I can send
to anyone.

Something can be wrong in my code, but if I am writing not wrong ...

thats it,

Fernando
maverick@elogica.com.br






> Hi, (sorry for BAD english),
>
> I have made modifications in one program to supports OmniOrb4.
> The same program, depending on its functionality, act as client or server.
>
> I have implemented BIDIR policy with
>      ...
>      { "clientTransportRule",  "* unix,tcp,bidir" },
>      { "serverTransportRule",  "* unix,tcp,bidir" },
>      { "oneCallPerConnection", "0" },
>      { "offerBiDirectionalGIOP", "1" },
>      { "acceptBiDirectionalGIOP", "1" },
>      ...
> and
>   pl.length(1);
>   a <<= BiDirPolicy::BOTH;
>   pl[0] = orb->create_policy(BiDirPolicy::BIDIRECTIONAL_POLICY_TYPE, a);
>   poa = poaRef->create_POA("myBidirPolicy", pman, pl);
> ...
>
> The first time my client narrow a reference to the server, everything
works
> fine. The client pass a callback
> reference to the server, and both sides can invoke calls without any
> problem, in BIDIR mode.
> Good to bypass firewalls ...
> The problem I have occurs when any side die. IE, if the server die and
> restart, and the client
> try to narrow a new T_var, I have a :
>
> [2002-12-02 08:33:49][Information] - omniORB: LocateRequest to remote:
> root<0>
> [2002-12-02 08:33:49][Information] - omniORB: AsyncInvoker: thread id = 6
> has exited. Total threads = 5
> [2002-12-02 08:33:49][Information] - omniORB: AsyncInvoker: thread id = 8
> has exited. Total threads = 4
> [2002-12-02 08:33:59][Information] - omniORB: throw TRANSIENT from
> giopRope.cc:321 (NO,TRANSIENT_CallTimedout)
>
> If i dont apply BIDIR policy, and not offer and or accept
BiDirectionalGIOP,
> the problem not occurs.
> Any side can die and restart without any problem.
>
> The problem occurs when I have a BIDIR conection, and any side restarts.
>
> I observed  in giopimpl12.cc the code below :
> ...
> /*
>   $Log: giopImpl12.cc,v $
>   Revision 1.1.4.18  2002/11/26 16:54:35  dgrisby
>   Fix exception interception.
>  ...
> // I suppose the "GIOP::CloseConnection" message is received
> // when the other side is dying, in IIOP 1.2.
> void
> giopImpl12::unmarshalWildCardRequestHeader(giopStream* g) {
> ...
>   case GIOP::CloseConnection:
>     if (g->pd_strand->biDir) {
>       // proper shutdown of a connection.
>       // XXX what to do?
>     }
>     inputRaiseCommFailure(g);
>     break;
>  ...
>
> I dont know if is related. In more then 20 days I have made dozens of
> changes in my code, and does not work.
> Alias, I allways redo my changes, because appears the rigth to me.
>
> ??????????? ~8() I am becaming crazy ;..;uhuhauhuauh :-) (Bjorn, be
patient
> :-))
>
> I really needs help ...
>
> thanks in advance,
>
> Fernando A. de Araujo Filho
> maverick@elogica.com.br
>