On 2013/6/20 21:31, Godbach wrote: > On 2013/6/20 21:18, Willy Tarreau wrote: >> Hi Godbach, >> >> On Thu, Jun 20, 2013 at 09:07:57PM +0800, Godbach wrote: >>> Hi, Willy >>> >>> I have noticed that "half-closed timeout" appears in ROADMAP file. >>> That't the issue I have tested several days ago. >>> >>> I have done a test under such conditions: >>> 1) block the response from server by iptables rules. >>> 2) client closes connection after sending request to haproxy ASAP. >>> >>> and enabled following options in haproxy: >>> option http-server-close >>> option http-pretend-keepalive >>> >>> I want to test whether haproxy will close both frontend and backend >>> connections under the above conditions. No matter I closed connection >>> from client with FIN or RST packet, the backend connection will keep >>> established and not be closed until the related timeout expired. The >>> only difference is that the connection will disappear when closed with >>> RST but enter into CLOSE_WAIT status when closed with FIN. The latter >>> should be so called half closed. >>> >>> After reviewing the codes and testing, it seems that haproxy will not >>> care about the events occur on front connection until it gets response >>> from the related backend connection. As a result, both FIN and RST >>> packets from client will be ignored. It should be harmful for servers to >>> keep a lot of established connections in this test condtion. >>> >>> I am wondering that what I have analysed is correct or not. If correct, >>> it should be necessary to care about the events on frontend connection >>> even that haproxy has not got response from backend server. >> >> Your analysis is correct, but you missed one case which is designed to >> solve your issue : if you enable "option abortonclose", then the close >> from the client will be propagated to the other side. >> >> Best regards, >> Willy >> >> > > Hi, Willy > > Thank you for your time. > > Yes, it works as expected with option abortnoclose enabled. I should > read the configuration manual more carefully. > > Best Regards, > Godbach >
Hi, Willy There is a further test about option "abortonclose" and "nolinger" I have done under the condition that reponse from server is blocked with iptables rule as follows: 1. only enable abortonclose Client aborts the request(without reading) with FIN, haproxy will not care about the event on frontend connection which will be closed when the related timeout expired. Client aborts the reqeust with RST, haproxy will close frontend connection ASAP, and the backend connection in haproxy enters into FIN_WAIT1 status. Haproxy should have sent FIN to server but have not received FIN from server. 2. Both enable abortonclose and nolinger No matter FIN or RST is sent by client to abort the reqeust, both frontend and backend connections will be reset ASAP. So in my scenario, I should both enable abortonclose and nolinger. There is an advice for using nolinger in manual: For this reason, it is not recommended to use this option when not absolutely needed. You know that you need it when you have thousands of FIN_WAIT1 sessions on your system (TIME_WAIT ones do not count). It means that I can enable option nolinger if a lot of FIN_WAINT1 sessions, in other words, ther servers are slow. -- Best Regards, Godbach
