[omniORB] Bidirectional problem

[Luke Tunmer]

I've been a great fan of omniORB for many years, but I've recently 
encountered a problem that could threaten CORBA in our product by our PHBs.

I need to set up bidirectional server/clients for the usual firewall 
reasons, but I'm getting weird behaviour. Only about one if five of the 
narrows to a the server root object succeed. I know that this sounds 
like a timing issue, but when it does fail the exception is a protocol 
error:

omniORB: From endpoint: giop:tcp:127.0.0.1:5024. Detected GIOP 1.2 
protocol error in input message. giopImpl12.cc:228. Connection is closed.


More details:

I'm running on WinXP, with omniORB-4.0.4 and omniORBpy-2.4. Both server 
and client are written in Python.

I have attached to this email a small bit code, derived from the bidir 
echo callback example, that illustrates this problem. To reflect what my 
real product does, I've implemented a "root finder" object that is 
activated with the omniINSPOA to give it a well-known object id. This 
object simply returns an object reference to the main server object. It 
is this object that is activated on a POA that implements the bidir 
policy. I've set up the usual ORBofferBiDirectionalGIOP, 
ORBofferBiDirectionalGIOP,
ORBserverTransportRule, ORBclientTransportRule arguments to both server 
and client.

What is strange is that the 4-times-out-of-5 failures happen when the 
client is narrowing to get a reference to the object that is not even on 
a POA with bidirectional policy. If the narrow does succeed, then the 
whole test will succeed.

Included in the zip is the idl file, a bat file to compile the idl, a 
bat file to run the server, and a bat file to run the client. Edit the 
bat files to point to your omniORB and omniORBpy distribs.

If a "-b" argument is given to the both the server and the client then 
both will be offering and accepting bidirectional comms. Without the -b 
argument then no bidir is enabled, and everything works fine. I've used 
-ORBtraceLevel 50, and this has not shed any light on it.

Here are some of the details to help anyone cut to the chase:

* Objects in the Server:
  - RootFinder - published on omniINSPOA, given a simple string id. A 
get method returns a reference to the CallbackServer object.
  - CallbackServer - published on a bidir POA if "-b" is on the command 
line, otherwise the root POA. The important method is one_time, which is 
given a CallBack object to echo a message to. It's this communication to 
the CallBack object that needs to be bidirectional.

* Objects in the client
  - A reference to the RootFinder is obtained by narrowing from a 
corbaloc string.
  - A reference to the CallbackServer is obtained by calling get() on 
the RootFinder.
  - CallBack. A reference to this is handed over on the one_time method.

Any insight into what could be going wrong here would really be appreciated.

Regards,
Luke

-------------- next part --------------
A non-text attachment was scrubbed...
Name: bidir_example.zip
Type: application/zip
Size: 3306 bytes
Desc: not available
Url : http://www.omniorb-support.com/pipermail/omniorb-list/attachments/20040929/6802e0fe/bidir_example.zip