Mina source reading: The server-side NIO-based processing process

In front of the source, there is no secret. After reading the prototype, Spring, Tomcat, and JDK parts, digester and so on source code, learn a technology, understand the source code has become the necessary process. Also deeply feel the source code before, no secret meaning, at the same time also appreciate the benefits it brings to me. At the same time, also hope that all developers, regardless of the front end, if there is time, try to look at the source bar.

Next go to the point, here to do an analysis of the Mina process. Because it means analyzing the NIO process, it is also the process of nio execution.

First look at the approximate structure of the main classes in Mina:

Next look at the entire life cycle of Mina:

1. Initialization analysis of Niosocketadaptor

When initializing, set dependent dependencies such as listeners, Sessionconfig,handler, executor, etc., this process has nothing to say.

2. Start and receive requests

The starting entry is bind (socketaddress), first look at this part of the sequence diagram:

This stage,

2.1 Put Serversocketchannel to selector to manage. Corresponds to the regiesterhandlers () operation in the sequence diagram.

2.2 Receiving Socketchanel

1) Use Serversocketchannel to receive Socketchannel.

2) package The received Socketchannel into a iosession,

3) added to the newsessions queue.

In addition, Iosession is bundled into the selectionkey associated with Socketchannel in a attachment manner. The purpose of this is to get the iosession directly from the key after Selector.select ().

Corresponds to the Processhandler () operation in the sequence diagram.

3. Processing Request Analysis

Processing the request is done by Ioprocessor, first take a look at this part of the sequence diagram:

This phase:

3.1 Call Selector.select () to see if there is a handle to the Socketchannel

If not, end this round of processing. If so, follow-up action is performed.

3.2 The newly added session is processed by Handlernewsessions (). The process is:

1) Remove the iosession from the newsessions queue,

2) is set to non-blocking and is registered to selector in read mode, which is selector to take over these socketchannel.

3) Create filterchain for Iosession

4) Place the session in the Managedsession collection.

5) Trigger session creation Complete event.

3.3 Traffic control treatment.

This procedure corresponds to the operation is Updatetrafficmask ().

Sometimes, we need to control whether a read operation is performed in the program, or pause the read operation. To implement this function, you can use Iosession's Resumeread () or Supendread (). However, although these two methods are called in the program, to really control the IO, you have to do this by registering an operation of interest. This is not done in the program.

In this process, you are actually completing an unfinished operation to help the application complete.

3.4 According to the interest event to deal with accordingly.

This procedure corresponds to the process () operation in the sequence diagram.

1) Get all the selectionkey that can be processed by Selector.select (time_out)

2) According to Selectionkey, take the bundle with the iosession.

3) handle events of interest.

If you are interested in reading, go to read data, business process flow. From the sequence diagram, you can see that the data was read from Socketchannel, then passed through Filterchain and finally reached Iohandler.

If you are interested in writing, enter the attribute data processing process. For all iosession interested in writing, then put it in the flushingsessions queue.

4) After each session is processed, the associated Selectionkey is removed from the set<selectionkey> selected from 3.1.

3.5 Handle the session that is interested in writing the event.

This process corresponds to the flush () operation in the sequence diagram.

If the Session.write () operation is used in the application, such as a sample program. The session will be placed in the flushingsessions queue.

The procedure is:

1) is to remove the session from the Flushingsessions queue

2) Clear Write interest

3) Handle the Write request queue (Writerequestqueue) in the session, that is, write the data in each write request in Writerequestqueue to Socketchannel.

4) If you have not finished writing, and there are remaining, register again to write interest.

5) If it is not finished, put it in the flushingseesions queue again.

3.6 Cleanup session that needs removal

This process corresponds to Removesessions () in the sequence diagram.

In the 3.2 to 3.5 process, the associated session will be placed in the Removingsessions queue if the process is exception, or if the connection to the client is broken.

The processing of this process is:

1) Remove each session from the Removingsessions queue

2) If the session is in the processing phase, clean up the writerequestqueue, call Selectionkey.cancel () to cancel the management of selector.

3) If the session is still in the unhandled phase, which also exists in the newsessions queue, it is removed from the newsessions queue.

3.7 Doing idle processing

Corresponds to the notifyidlesessions () operation in the sequence diagram.

Mina source reading: The server-side NIO-based processing process