Netty Reliability Design Three

Connection Interrupt Handling

After a connection is established between the client and the server, if the connection is unexpectedly interrupted, Netty also releases the connection handle resource in a timely manner (because TCP is a full-duplex protocol, both sides need to close and release the socket handle before the handle leaks, such as a handle leak without special processing). The principle is as follows:
Io.netty.buffer.AbstractByteBuf.writeBytes (scatteringbytechannel, int) is called when the data is read, Then call io.netty.buffer.ByteBuf.setBytes (int, scatteringbytechannel, int), The SetBytes method calls Nio.channel.read, if the current connection has been unexpectedly interrupted, receives a closedchannelexception exception thrown by the JDK NiO layer, and returns 1 directly after the SetBytes method catches the exception.
In the Niobyteunsafe.read method, it is found that the currently read byte length is-1, which is called Io.netty.channel.nio.AbstractNioByteChannel.NioByteUnsafe.closeOnRead (Channelpipeline) method, and then call Io.netty.channel.AbstractChannel.AbstractUnsafe.close (Channelpromise) to close the connection release handle resource. Refer to the relevant code:

Niobyteunsafe.read method public void Read () {... boolean close = false;            try {... int localreadamount = doreadbytes (BYTEBUF);                if (localreadamount <= 0) {... close = Localreadamount < 0;            Break }            ...        }        while (...);            ... if (close) {Closeonread (pipeline);        Close = false; }} catch (Throwable t) {...} finally {...}} Niosocketchannel.doreadbytes method protected int doreadbytes (Bytebuf bytebuf) throws Exception {return bytebuf.writebyte S (Javachannel (), bytebuf.writablebytes ());} Abstractbytebuf.writebytes method public int writebytes (scatteringbytechannel in, int length) throws IOException {ENSUREWR    itable (length);    int writtenbytes = SetBytes (Writerindex, in, length);    if (Writtenbytes > 0) {writerindex + = writtenbytes; } return writtenbytes;} UnpooledheapbytebUf.setbytes method public int setbytes (int index, scatteringbytechannel in, int length) throws IOException {ensureaccessible    ();    try {return In.read (Bytebuffer) Internalniobuffer (). Clear (). Position (index). Limit (index + length);    } catch (Closedchannelexception e) {return-1; }}

Traffic shaping

Generally large-scale systems are composed of multiple modules, in the deployment of different modules may be deployed on different machines, such as our project, at least 5 parts, less embarrassed to take out to see people. In this case, the system will run with a large number of upstream and downstream parts of the communication, but because the different servers, whether from the hardware configuration, or the system module business characteristics are different, which leads to the processing power to the server, as well as the load of different time periods of the server is a difference, This can lead to problems: upstream and downstream message delivery speed and the downstream parts of the message processing speed out of balance, the downstream parts received a lot more than its processing capacity, resulting in a large number of services can not be processed in a timely manner, may even lead to the downstream server is overwhelmed.

The traffic shaping mechanism is provided in the Netty framework to cope with this scenario by controlling the number of bytes sent/received within the server unit time to handle the relatively balanced state of the upstream and downstream servers. Traffic shaping in Netty consists of two types of traffic shaping for a single connection, and one for global or all-connected traffic shaping. These two ways of traffic shaping principle is similar, but the scope of traffic shaper is different, one is global, one is created after the connection is established, the connection is closed after being recycled. Globaltrafficshapinghandler handles global traffic shaping, Channeltrafficshapinghandler handles single-link traffic shaping, and traffic shaping handles three important parameters:

• Writelimit: You can write up to multiple bytes of data per second.
• Readlimit: The maximum number of bytes of data that can be read per second.
• Checkinterval: The interval between traffic checks, default 1s.

As an example of read operations, traffic shaping works in the following general way:

• Initiates a timed task that executes once every checkinterval milliseconds, clears the cumulative number of read-write bytes in the task and restores the last traffic shaping check time to 0.
• Performs a read operation, triggering the Channelread method, recording the number of bytes currently read and accumulating the number of bytes read by all read operations after the last traffic shaping check.
• Calculates the current traffic based on the time interval and the number of traffic read determines whether the current read operation has caused the number of bytes read per second to exceed the threshold Readlimit, the formula is: (bytes * 1000/limit-interval)/10 * 10, wherein, Bytes is the number of bytes that have been read by all read operations since the last traffic shaping check, and limit is the number of milliseconds that the current time elapsed since the last check, and if the formula calculates a value greater than a fixed threshold of 10, then the number of traffic is exceeded. Then the read operation is put into the delay task, the delay of the number of milliseconds is the above formula calculated value.

The following is the relevant code:

Abstracttrafficshapinghandler.channelread method public void Channelread (final Channelhandlercontext ctx, final Object    msg) throws Exception {Long size = calculatesize (msg);    Long curtime = System.currenttimemillis ();        if (trafficcounter! = null) {//Increment bytes Cumulative number trafficcounter.bytesrecvflowcontrol (size);            if (Readlimit = = 0) {//No Action ctx.firechannelread (msg);        Return                }//Compute the number of MS to wait before reopening the channel long wait = gettimetowait (Readlimit,        Trafficcounter.currentreadbytes (), Trafficcounter.lasttime (), curtime); if (wait >= minimal_wait) {//At least 10ms seems a MINIMAL//time in order to//try to limit                The Traffic if (!issuspended (CTX)) {ctx.attr (read_suspended). Set (true); Create a Runnable to reactive the read if needed.            If One was create before it'll just be    Reused to limit object creation attribute<runnable> attr = ctx.attr (Reopen_task);                Runnable reopentask = Attr.get ();                    if (Reopentask = = null) {Reopentask = new Reopenreadtimertask (CTX);                Attr.set (Reopentask);            } ctx.executor (). Schedule (Reopentask, wait, timeunit.milliseconds); } else {//Create a Runnable to update the next handler in the chain. If One was create before it would//Just be reused to limit object creation Runnable Bufferu Pdatetask = new Runnable () {@Override public void Run () {CT                    X.firechannelread (msg);                }                };                Ctx.executor (). Schedule (Bufferupdatetask, wait, timeunit.milliseconds);            Return }}} ctx.firechannelread (msg);} AbsTracttrafficshapinghandler.gettimetowait method private static long gettimetowait (long limit, long bytes, long lasttime, long    Curtime) {Long interval = Curtime-lasttime;    if (interval <= 0) {//time is too short, so just lets continue return 0; } return (bytes * 1000/limit-interval)/10 * 10;} private static class Trafficmonitoringtask implements Runnable {... @Override public void run () {if (!co        Unter.monitorActive.get ()) {return;        } Long EndTime = System.currenttimemillis ();//restore cumulative bytes, lasttime variables counter.resetaccounting (endTime);        if (trafficShapingHandler1! = null) {trafficshapinghandler1.doaccounting (counter);                                                            } counter.scheduledfuture = Counter.executor.schedule (this, Counter.checkInterval.get (),    Timeunit.milliseconds); }}

Netty Reliability Design Three