[omniORB] Remote method blocks

[Duncan Grisby]

On Tuesday 4 November, Masaaki Sekiya wrote:

> I run eg2clt with -ORBtraceLevel 25 in 3 cases as below.
> 
> 1. ServerObject exists in the remote host (10.21.161.27)  omniORB4.1.3
>    -> eg2clt works fine.
> 2. ServerObject doesn't exist in the remote host          omniORB4.1.3
>    -> eg2clt blocks
> 3. ServerObject doesn't exist in the remote host          omniORB4.1.2
>    -> eg2clt throws COMM_FAILURE exception

Both the failure cases show something odd happening. The 4.1.3 case just
shows that the call is blocked in connect(). What exactly is going on at
the server end?  Is there a server process running?  Is the server
machine contactable?

The 4.1.2 case is very fishy. These lines show that the system is very
confused:

omniORB: Client attempt to connect to giop:tcp:10.21.161.27:50743
omniORB: Client opened connection to giop:tcp:255.255.255.255:65535

That suggests that the OS has done something bizarre when omniORB opened
a connection and asked for the peer address.

> I noticed the difference 2. and 3.
> In the log of 3, "AsyncInvoker: " is output before "Client attempt to 
> connect to",
> in the log of 2, "AsyncInvoker: " is output after  "Client attempt to 
> connect to".
> Does it have something with blocking behavior ?

No, that's unrelated. That message comes from a separate thread, so it's
normal for it to appear at slightly different times.

You can show thread ids in your traces with -ORBtraceThreadId 1. I'd
suggest also using -ORBtraceTime 1 which shows times in log messages.

What trace output do you get from the server?  What happens if you use
telnet to connect to the server's port (which you can see in the trace
messages or by using catior)?  Does eg2 work when client and server are
on the same machine?

Cheers,

Duncan.

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