Not releasing ESTABLISHEd connections

[Umesh Karekar]

Hi all,

I am having rp3410 with hp-ux11.11 acting as a web server with tuxedo instance.
my clients are talking to port 4200(TCP).
Connection gets established on 4200 and later on passed to 4201, 4202 ....
Though client quits the application, the connection on 4200 remains as established.
This way it gets accumulated till it reaches max_file limit, then i have to reset the service.
can anyone suggest a cause and solution for this problem? Or if any patch is available to resolve this issue?

Regards

Umesh

[Muthukumar_5]

Check patch availablity as,

http://www2.itrc.hp.com/service/patch/crumbRequest.do?crumb=patch.breadcrumb.main&BC=

Tune socket ESTABLISHED problem with dsniff tool. Search for it.

--
Muthu

[Ivan Ferreira]

Try enabling tcp keepalive.

http://forums1.itrc.hp.com/service/forums/questionanswer.do?threadId=974906

[Steven E. Protter]

Shalom Umesh,

Ideas:
1) Patching as other have indicated.
2) Raise max files limit and max_uprc in the kernel
3) See about applicaiton/tuxedo patches.
4) Perhaps write a script that kills dead processes if there is a way to determine this by script.

SEP

[rick jones]

When you say your clients are talking to port 4200 and then passed-on to 4201 etc what exactly do you mean for the passing-on? HTTP redirects?

When they get redirected, does the web server remember to close the connection that came-in to port 4200? Does the client remember to close the connection it made to port 4200, using a _graceful_ TCP close rather than the kludge of using SO_LINGER and an abortive close?

TCP_KEEPALIVES may kludge around the problem, but only if the client went away using abortive close and the RST was lost (RST's are not retransmitted like FINs are - FIN's are the TCP segments sent for graceful close of a connection).

Also, if there is any forking going-on, keep in mind that a fork will increment the reference count for a socket, and the TCP connection will not be closed until the last reference is closed - which means that both the parent and the child have to call close on their respective file descriptors - or both have to exit.

[Umesh Karekar]

Hi Rick,


Tuxedo is configured to run JSL on 4200
And every JSL connection has 11 JSH (handlers) configured on 4201 - 4211.
Again JSH has multiplexing factor defined as 5. (ie. 11*5 connections).

Ideally, clients should connect on JSL(4200). And JSL passes on the requests to any of its JSHs. After that JSL should quit the connection. This works fine on LAN with max 55 simultaneous connections.
But for VSAT, connections on 4200 keeps accumulating.

Regards

Umesh

[rick jones]

Start taking some tusc traces of the server, I'm guessing you will see that the main server isn't closing the 4200 connection after it hands-off to 4201 etc. I'd make it a verbose tusc trace with lwpid printing (-v and -l options in addition to any others you use)