This is proper RFC/TCP connection behavior since the
fin_wait socket left on the Application Server will be closed out
by the operating system's TCP timers. On the Web server side of the
connection, the socket is still in the close_wait state which
will not be cleaned up by the operating system, but the socket will be
cleaned up by the Web server plug-in. The connection will be reset by the
plug-in the next time the connection is used again or when the Web server
process exits.
When the next client request comes into the plug-in and the request has
been mapped to an application server, the plug-in will try to reuse any
and all existing connections that go to that Application Server's port. If
any of the known connections are found to be in an unusable state like
close_wait, the connection(s) will be reset. When there are no
further known connections to be used, the plug-in will establish a new
connection to the Application Server port.
The Application Server HTTP plug-in does not actively monitor the TCP
connection state between itself and the Application Server for performance
reasons. When running in a production environment, there will be
continuous client requests, and all of the plug-ins to Application Server
connections will be reused. The number of close_waits left
hanging around will be far lower.
When in a testing environment, you may easily have 1000 simultaneous
client test requests come in and then nothing further; so these
close_waits will not go away. These close_waits will be destroyed
when the next client comes in that can reuse the connection to that
Application Server port.
|