> This problem occure when we have the load blance to to see if the C:D is > up by probing the port , this is corrected.
Yes, that would clearly cause it. I don't know of any commercially available load balancers that understand the C:D protocol well enough to do a layer 4 transaction to verify availability. > Now it seems we have user > write API to to talk to C:D and it causing the problem. If that user is doing something really dumb like just aborting the connection without properly shutting it down, then C:D is doing exactly what it's supposed to do (waiting for the 2 minute timeout to declare that the socket peer has gone away), and the user program (and most probably, the user) needs correcting. Also, is this user testing against the production instance? If so, why? What exactly is this API supposed to accomplish, if you can share the info? Maybe there's a different way to accomplish what you want. > Do you guys feels reducing the default 180000 for the TCP-TIME-WAIT > BUCKETS POOL SIZE will correct the problem? No. Masking the problem won't really help you. ---------------------------------------------------------------------- For LINUX-390 subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390
