Close_wait state

[Mike Campbell]

We have an ftp process that picks up a file from an external server and returns it to Cloverleaf for processing.  We are finding that the netstat

state of close_wait is increasing throughout the day.  Is anyone else seeing this behavior?  

We are using an ftp_file_processing proc.  The read interval is 10, scan interval is 60 and max messages is 10.

I’m wondering if the process correctly quits when done with the ftp.  

Any ideas or suggestions?  

Vs. 5.7 on AIX platform.

Thanks.

Topic

[Robert Gordon]

The internet during peak moments of the day has different requirements, according to the “lowest cost route” rule that is used for the internet your message packet can either be more or less time according to how many users are online.  i.e.  Its 12:01pm here and in England it is 6:01pm, usually people should be eating, but then again they could be logging into Facebook and so your message packet which had a travel route to Germany from New York, has a travel itinerary from Florida, to California, to Hawii, to Russia, to China, to India, and finally Germany.  The evidence will become clear if you ping the external host, from inside your network, and from outside your network.  And remember that even conventions with those snazy display screens, are usually hocked up to the office somewhere in Patagonia.

:::;;;|||

[Ted Viens]

I actually logged onto research this very thing.

I am encountering this issue as well.  We are using 5.7 on AIX.  I am polling for a file on an external system running AIX.

The symptom that I am seeing is that the the FTP Get being run by the IB thread is not closing the connection cleanly.  So as time goes by, as in your case, the number of connections in CLOSE_WAIT on the external with a FIN_WAIT2 on the Cloverleaf server.  After each attempt the connection is not let go.

This has caused production issues and continues to be a risk.

[Jim Kosloskey]

Frequently this can be a problem with the foreign system.

Typically FTP does not immediately release the connection when a close is requested by the connecting system (Cloverleaf being the connecting system in this case).

I think there are delays that can be adjusted on the foreign system. However, if the foreign system expects a lot of activity they may not want to adjust that delay down for their own reasons.

If I recall correctly there is some timing on the O/S IP as to how long to wait for the final close before finally actually killing the connection. If that is true care needs to be taken when adjusting that setting as well as it may affect the real time (TCP/IP) work.

This is one reason why I do not recommend here that we mix our workloads on one platform. We do without significant issue – but we are not doing much FTP with external systems.

Bottom line I would not necessarily suspect Cloverleaf as being the issue.

I recall there are some sources on the Web regarding this exact issue with FTP and they give some insight as to the realities of FTP. I am sorry I do not have more specifics but the FTP I have done has not had this issue for quite a while and I do not have exact recall.

email: jim.kosloskey@jim-kosloskey.com 29+ years Cloverleaf, 59 years IT - old fart.

[Mike Campbell]

We did some fine tuning on the setup for the FTP which resulted in somewhat fewer of the Wait_stat being generated.  We eventually scheduled a job to run every 4 hours to stop and start the particular thread.  Once the thread is stopped, all of the WAIT’s were released.  That seems to keep things in order.

[Ted Viens]

This issue was not seen on 5.4.1.  It was only after upgrading to 5.7that this CLOSE_WAIT issue came about.  It could be related to the OS and that is being explored.

We are running 5.7 rev2 on AIX 6.1.

[Author]

Replies