AW: [omniORB] Client behaviour on receiving CloseConnection

[Kiesswetter, Florian (Florian)]

Duncan,

thanks for this explanation. There is no issue with this behaviour, just wondered if the sequence of packets is quite normal.
I took a closer look at the sequence as we run into the bug of omniORB 4.0.3 where a recoverable error on the tcpEndpoint leads to closing of the socket in case the connection is not established. I can reproduce the failure on Solaris where a RST after a connection establishment leads to shutdown scenario. We also noticed the behaviour in our productive environment on many omniORB server running VxWorks 5.5.
BUT: I can not reproduce the failure on my VxWorks test systems and I am still looking for the sequence which caused my servers to fail ( but (un)fortunately it is not the client sequence that  I've been reporting in this thread)

Any ideas on this question (which I raised already in another thread)?

cheers, 
Florian

> ----------
> Von: 	Duncan Grisby[SMTP:duncan at grisby.org]
> Gesendet: 	Freitag, 31. M> ärz 2006 19:42
> An: 	Kiesswetter, Florian (Florian)
> Cc: 	'omniorb-list at omniorb-support.com'
> Betreff: 	Re: [omniORB] Client behaviour on receiving CloseConnection 
> 
> On Tuesday 28 March, "Kiesswetter, Florian (Florian)" wrote:
> 
> > I am just wondering about the scenario where an omniOrb server sends a
> > CloseConnection for a omniORB client connection and the client will
> > perform a request afterwords:
> >
> > What I can see on ethereal traces is, that the close connection is
> > sent and acknowledged. Upon trying to invoke the method "statusAudit",
> > the client performs this request on exactly the connection which has
> > been requested to close. Immediately after that it sends a FIN/ACK for
> > this connection and establishes a new connection and perfoms the
> > request again.
> > 
> > Why does the Client not close the socket immediately and establish a
> > new connection for the first invocation? Is that behaviour
> > specified/agreed (I thought from the specs that it clearly states that
> > upon receiving a CloseConnection, the socket has to be closed)?
> 
> The client doesn't have a thread monitoring the socket, so it's not
> until it tries to send on it that it is in a position to notice that the
> connection has been closed. The alternative would be to select() or
> similar on the socket before trying to use it, just in case it had
> closed, but that would just slow everything down in the normal case that
> the connection is still open.
> 
> Are you experiencing a problem with this behaviour or are you just
> wondering why it's the way it is?
> 
> Cheers,
> 
> Duncan.
> 
> -- 
>  -- Duncan Grisby         --
>   -- duncan at grisby.org     --
>    -- http://www.grisby.org --
>