[omniORB] sockets in CLOSE_WAIT for 2 min

[Slawomir Lisznianski]

I don't have a problem with TIME_WAIT state. It's the CLOSE_WAIT state
that I was inquiring about.

Regards,
Slawomir
 



On Mon, 22 Aug 2005 10:11:16 +1000, amos at amos.mailshell.com said:
> On Fri, 2005-08-19 at 08:55 -0500, Slawomir Lisznianski wrote:
> > Hello,
> > 
> > I noticed that after a graceful shutdown from a client (after issuing
> > ORB destroy() and all that), the server sockets are in CLOSE_WAIT state
> 
> That's the TCP requirement, in case a lost packet finally arrives -
> if the kernel doesn't know that it is part of an old connection on
> that particular port/ip-address quadruplet then this old packet may
> be taken to be part of another connection. Leaving the socket on
> TIME_WAIT for two minutes will prevent another connection from using
> that exact port/ip for that while. It shouldn't practically bother
> creation of other connections.
> 
> Also, these sockets in TIME_WAIT state do not take up the server's
> file descriptors, only some kernel data structures.
> 
> > for about 2 minutes. Shouldn't these sockets be closed right away? Our
> > servers are hit by a lot of short-lived clients and the concern is that
> > we may run out of available file descriptors. Using
> > oneCallPerConnection=0, to conserve resources, doesn't really work
> > because of the occasional assertion in the iiopRoap.cc file (line 374,
> > omniORB 4.0.6) while in this mode (refer to previous post for details).
> 
> This is unrelated to the above question - try to increase the number
> of maximum file descriptors per process. The way to do this depends
> on your particular environment.
> 
> > 
> > Any advice?
> 
> Hope this helps.
> 
> Cheers,
> 
> --Amos
> 
> 
> _______________________________________________
> omniORB-list mailing list
> omniORB-list at omniorb-support.com
> http://www.omniorb-support.com/mailman/listinfo/omniorb-list