現象：客戶端session.close之后，並沒有提出，客戶端程序一直hold在那里；
解決：調用了session.getService().dispose(false)方法后，客戶端程序完成了退出
原因分析：一個connetor創建了之后，在創建之初職責是創建連接，session即使關閉了並不會觸發Service關閉（connector以及Acceptor基類都是service），如果想要退出程序，只有通過session獲得其所在容器（Service），對Service進行關閉（dispose）才會關閉；在測試過程中發現要退出只能是調用dispose(false)，不做等待，如果調用了dispose(true)仍然處於Hold狀態。
現象：客戶端session.close()之后，服務器端CPU直線上升；而且服務器端並沒有觸發SessionClose事件；只有當session.getService().dispose(false)之后，才會觸發sessionClose事件；
解決：重寫了IoHandler里面的inputClose方法，手工調用session.Close；
原因分析：看了一下inputClose的注釋：Handle the closure of an half-duplex TCP channel，說明是處理對端鏈接關閉的事件；如果你的Handler是繼承自IoHandlerAdapter的話，那么這個基類里面已經實現了inputClose，並且在里面關閉了session；但是如果你繼承的是接口IoHandler，那么當對方關閉的時候，通知的是MINA的inputClose方法；將會因為網絡鏈接單方面關閉，導致服務器端去不斷輪詢客戶端；
另外對於調用session.getService().dispose(false)之后，才會觸發sessionClose，這是因為客戶端connetor的終止，將會通知服務器端，服務器將會遍歷該和該端的所有session（可能是根據RemoteAddress），然后調用對應session的close方法，進而觸發了sessionClose事件；