測試場景1：已經進入應用的請求，請求尚未響應完畢。將haproxy此應用的狀態改成下線。請求是否能夠正常響應到客戶端。
測試場景2：已經進入應用的請求，將應用Kill -9 關閉掉，haproxy是否能夠自動重試，將請求分發到其他應用。
1.在controller加入代碼：
@RequestMapping("/testSlowResponse.do")
@ResponseBody
public String testSlowReponse() throws Exception{
for(int i=0;i<=30;i++){
Thread.currentThread().sleep(1000l);
System.out.println("res:" + i+" wait");
}
return "OK";
}
2.haproxy配置：
listen admin_status
mode http
bind 0.0.0.0:48800
stats enable
stats uri /xxh_status
stats auth xxh:xxh666
option httplog
listen web_haproxy_test
mode tcp
bind 0.0.0.0:8003
option tcplog
option httpchk /xxh/guest-access/check.jsp (重命名此JSP來使應用下線)
balance roundrobin
server web_77_1 192.16.50.77:8001 check port 8001 inter 3s rise 2 fall 3
server web_77_2 192.16.50.77:8002 check port 8002 inter 3s rise 2 fall 3
server web_77_3 192.16.50.77:8003 check port 8003 inter 3s rise 2 fall 3
場景1：
1.1.用瀏覽器訪問/testSlowResponse.do
1.2.看三臺服務器的日誌，正在打印的就是收到請求的應用
1.3.重命名次應用的check.jsp爲check.jsp.bak。觀察到haproxy的監控頁面此應用變成紅色(即下線)
1.4.30S之後，瀏覽器能夠正常收到請求。
測試結果：已經進入應用的請求，即使在haproxy上將其改成下線，請求依然能夠的到正常響應。IE,CHROME都可以
場景2：
1.1.用瀏覽器訪問/testSlowResponse.do
1.2.看三臺服務器的日誌，正在打印的就是收到請求的應用
1.3.直接將該應用Kill -9 掉。
1.4.瀏覽器觀察到收到EMPTY_RESPONSE_BODY錯誤
1.5.但是瀏覽器會自動再次發起請求。
測試結果：已經進入應用的請求，即使kill -9 掉應用。haproxy不會向客戶端發送重定向請求，也不會將改請求分發到其他正常的應用。但是chrome瀏覽器根據EMPTY_RESPONSE_BODY錯誤自動發起了請求。但是IE瀏覽器不會。
總結：如果要優雅停機，正確的步驟應該是先將haproxy的應用逐個下線，避免此應用再收到新的請求，等待已經進入應用的請求都響應完畢。在部署，再將haproxy的應用逐個上線。雖然chrome內核會自動再次請求，但是我們並不能保證所有的客戶端的瀏覽器都用chrome.
如何知道所有請求都響應完畢：攔截所有的controller,添加atomicLong成員變量，每次請求進入加+1，結束減1（正常結束和異常都需要減）