Mina's Session.close

Phenomenon: After the client session.close, and did not propose, the client program has been hold there;

WORKAROUND: After calling the Session.getservice (). Dispose (False) method, the client program completes the exit

Cause analysis: After a connetor is created, the responsibility at the beginning of creation is to create the connection, and the session will not trigger a service shutdown (connector and Acceptor base class are service) if you want to quit the program, even if it is closed. Only the container (service) is obtained by the session, the service shutdown (dispose) is closed, and during testing it is discovered that the call to Dispose (false) is not done, and if Dispose is called (true) Still in hold.

Behavior: After the client session.close (), the server-side CPU rises linearly, and the server side does not trigger the Sessionclose event; only after Session.getservice (). Dispose (false) Will trigger the Sessionclose event;

Resolution: Rewrite the Iohandler inside the Inputclose method, manually invoke session. Close;

Cause analysis: Look at the Inputclose Note: Handle the closure of an Half-duplex TCP channel, which is the event that handles the off-end link If your handler is inherited from Iohandleradapter, then the base class has implemented Inputclose and closed the session inside, but if you inherit the interface Iohandler, then when the other person shuts down, The notification is the Inputclose method of Mina, which will be closed by the network link unilaterally, causing the server to continuously poll the client;

Also, Sessionclose is triggered after calling Session.getservice (). Dispose (false), because the client connetor is terminated, and the server side is notified. The server will traverse all sessions of that and that end (possibly according to remoteaddress) and then invoke the Close method corresponding to the session, triggering the Sessionclose event;

Mina's Session.close