[omniORB] Issues with persistent objects

[Duncan Grisby]

On Mon, 2011-02-07 at 10:26 +0100, Martin B. wrote:

> > That is intentional. What happens is that the client does not notice
> > that the connection has broken until after it has sent its request. You
> > snipped the bit of the omniORB log that shows the exception details but
> > you'll see that it has a completion status of COMPLETION_MAYBE. i.e. the
> > (...)

[...]
> WHY does the client not notice that the connection is broken?
> 
>  From what I understand, shouldn't the server properly close it's TCP 
> connection to the client when it's shutting down. Shouldn't the client 
> notice this disconnect?

The way TCP sockets work means that the client doesn't learn about the
disconnect until too late.

The sequence of steps a client uses to do a call is:

1. find an existing connection to the server, or open a new one
2. perform one or more send() calls to send the request
3. block in recv() waiting for a reply
4. potentially perform more recv() calls to receive all the data

If the server has closed the connection, it is common for the OS to
report success for the send() calls. It is generally only if a large
amount of data must be sent that send() returns an error.

It is thus only when the client has sent the request and blocks in
recv() that recv() returns an error and the client knows the connection
has broken. By that stage it doesn't know whether the server received
the request or not, hence the COMPLETED_MAYBE status and the lack of
automatic retry by default.

In some circumstances, if omniORB did a poll() or select() on the socket
before its send(), it would be able to see the error state. However,
that would still be vulnerable to exactly the same situation some of the
time, and it would slow down all calls, so omniORB doesn't do that.

Cheers,

Duncan.

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