[omniORB-dev] Server detection of a response that is not successfully sent to a client

[Duncan Grisby]

On Wednesday 1 October, "Steve Jibson" wrote:

> I have a question that I have not been able to find an answer to.  Any help
> would be appreciated.

This kind of question should be asked on the main omniORB list, not
omniORB-dev.

>   A client is set to timeout after 30 seconds.
>   He sends a request that takes a server 60 seconds to process and return a
> result.
>   The client gives up before the result is received.
>   The client "knows" that he gave up (because an error is raised).
>   The testing I've done shows that the server completes the processing of the
> request and returns the result (to nowhere).  The server seems completely
> ignorant of the fact that the client was no longer there to receive the
> result.
> 
> Is there a way for the server to "know" if the client is still there to
> receive the response?

In general, it's not possible for the server to reliably know. It's not
until it tries to send the response that it is in a position to notice
that the network connection has gone, and even then there are cases
where the server can think it has successfully sent the response, but
actually the client does not receive it.

With CORBA's rpc-style semantics, there's no way for your code to be
notified of the error even if the server does notice it.

> (In this particular case, I would want the server to "roll-back" the work he
> did, if he doesn't successfully pass off the result to the client.)

The usual approach to this kind of issue is to impose some higher-level
semantics on the use of CORBA calls, so the server can know what the
state of its clients is.

Cheers,

Duncan.

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