现象：客户端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事件；