Mina2.0 user manual Chinese version-Chapter 4 session in Mina

In Mina, a session is at the core: each time a client connects to a server, a new session is created and saved to the memory until the client is disconnected. Session is used to save persistent connection information, and some other types of information that may be required by the server during request processing are appended. This information takes effect throughout the session lifecycle.

The session status changes over time:

• Connected: The session has been created and is available.
• Idle: The session has not processed any requests within a specified period of time (this time can be configured ).
  • Read idle: No read request is processed within a period of time
  • Idle write: No write request is processed within a period of time
  • Read/write idle: No read request or write request is processed within a period of time
• Closing: the session is being closed. (the remaining cached messages are being written to the bottom layer for Refresh. The cleanup has not been completely terminated)
• Closed: The session has been closed and cannot be re-activated.

The following status chart shows all the possible states of a session and the State Transition Relationship between them: session configuration has many different parameters for a session that can be set:

• Message receiving buffer size
• Message sending buffer size
• Idle Time
• Write timeout

There are also some other configurations that depend on the specific transmission type used (see Chapter 6 Transmission) to manage custom attributes during system development, we usually need to save some data for later use, this usually requires a dedicated data structure, which is only associated with the current session. This is the data structure of the key-value combination "key-value", which can be used to store any data types required by developers. For example, if you want to track the total number of requests initiated by a user starting from a session, you can simply save the data to the map-associate the value by creating a key:

...int counterValue = session.getAttribute( "counter" );session.setAttribute( "counter", counterValue + 1 );...

There is a way to process attribute stored in the session: an attribute is a key-value pair, which can be added, deleted, read, and other operations in the session container.

This container is automatically created along with the creation of the session, and is cleared along with the termination of the session.

As mentioned above, the Custom Data container is a key/value container. By default, it is a map, but other types of data structures can also be customized. For example, sometimes we want to process long-time data or avoid storing large data in the memory: we can implement an interface and a factory, this allows the session to be created by calling our custom implementation. The following code snippet shows how a session creates the container during initialization:

protected final void initSession(IoSession session,        IoFuture future, IoSessionInitializer sessionInitializer) {    ...    try {        ((AbstractIoSession) session).setAttributeMap(session.getService()                .getSessionDataStructureFactory().getAttributeMap(session));    } catch (IoSessionInitializationException e) {        throw e;    } catch (Exception e) {        throw new IoSessionInitializationException(                "Failed to initialize an attributeMap.", e);    }    ...

The code of the factory interface that we need to implement when we want to customize a container of another type:

public interface IoSessionDataStructureFactory {    /**     * Returns an {@link IoSessionAttributeMap} which is going to be associated     * with the specified <tt>session</tt>.  Please note that the returned     * implementation must be thread-safe.     */     IoSessionAttributeMap getAttributeMap(IoSession session) throws Exception; }

Filter chain

Each session is associated with a series of filters. When receiving incoming requests or outgoing messages, these filters process the information. These filters are specific to each session. In most cases, we use almost identical filter chains for all sessions currently. However, it is also allowed to modify a separate session dynamically. For example, you can add a LOG filter to a specific session.

Statistics

Each session keeps a record of the session execution, for example:

• Number of bytes received or sent
• Number of messages received or sent
• Idle
• Throughput

And a lot of other useful information.

Handler

Finally, a session must be accompanied by a handler. It not only schedules messages to your application, but also simply calls the session's write () method to send the response back:

...session.write( <your message> );...

(Supplement: as the manual is constantly being updated, it may change. The last update date is. It is strongly recommended that you read the original document)