[Serdev] TCP Blocking Connect issue

[Jiri Kuthan]

At 01:36 AM 8/23/2004, Andrew Mee wrote:
>The TCP connection is available on the UA, why would it not be on the SER, I have no idea...
>
>Sorry I'll clarify, perhaps I have been unclear
>
>There are no TCP issues with SER, we can make quite a lot of calls for hours on end no problem, until a client crashes.
>this results in the following (see other emails for more depth):
>11(14986) ERROR: tcp_read: error reading: Connection reset by peer
>11(14986) ERROR: tcp_read_req: error reading
>Ok, we now restart the client at both ends
> From this point in we have continual TCP issues that result in (see other email for more depth):
>11(3048) ERROR: tcp_blocking_connect: SO_ERROR (111) Connection refused
>11(3048) ERROR: tcpconn_connect: tcp_blocking_connect failed
>11(3048) ERROR: tcp_send: connect failed
>Now I then restart SER (and leave the clients running)
>Relog the clients in again
>And then we have no problems at all until the client crashes and then SER problems reoccur.
>This is reproducible every time.
>
>My theory is that the TCP connections in SER are not being cleaned up properly when they dropped from the client end.
>This is SER 0.8.14 btw.

Thanks. I don't preclude this to be error cause despite the fact
that SER connects (ie it does not fail during attempt to reuse some TCP connection).
Still, can't it be that the dead UA's contact remain in server's user location 
database (I suppose it didn't unregister on crash) and incoming requests are
then forwarded to this dead TCP server? What do you see with "serctl ul show user at domain"?

-jiri