Shulou(Shulou.com)05/31 Report--

This article mainly introduces "what is the execution order of netty handler". In the daily operation, I believe that many people have doubts about the execution order of netty handler. The editor consulted all kinds of materials and sorted out simple and easy-to-use operation methods. I hope it will be helpful to answer the doubts of "what is the execution order of netty handler?" Next, please follow the editor to study!

The concept of handler reminds me of something else, just like interceptor in filter,spring in servlet. In handler, it can complete all kinds of work, such as the encoding and decoding of protocol flow, the interception of special information, the statistics of the number of requests, etc., or it can be said that all business-level things need to be completed in handler.

I will analyze the execution order of handler according to uplink and downlink. Today, let's start with downlink.

According to my initial imagination, all handler should be the same kind of thing, so the method of our business execution, that is, after we inherit the parent class provided by netty, the method of Override should be the same, but I found that this is not the case in actual use, sometimes it is a decode method, sometimes it is a messageReceived method, what is the reason for this? Based on this confusion, there is today's article.

The first is a diagram of stacktrace.

ProtocolAnaDecoder is a protocol parsing class I wrote myself, inherited from ByteToMessageDecoder, in which three methods are called in turn, channelRead (), callDecode (), and decode (). The decode is implemented by ourselves, and the other two methods come from the parent class.

Look at another picture.

NettyServerHandler inherits from SimpleChannelInboundHandler, where two methods, channelRead () and messageReceived (), are called in turn.

So far, I have basically solved my first doubt, which originally came from channelRead. So although this channelRead is implemented in various handler, its original definition comes from ChannelHandler, which is an interface. Its implementation, ChannelHandlerAdapter, can basically be regarded as the ancestor of all handler in netty. (the reason for the basics here is that there are two web-related handler interface that directly inherit ChannelHandler, but this is not the focus of our discussion today.)

Go on, it should be ChannelHandlerInvokerUtil.invokeChannelReadNow. Look at the code.

Public static void invokeChannelReadNow (final ChannelHandlerContext ctx, final Object msg) {

Try {

Ctx.handler () .channelRead (ctx msg)

} catch (Throwable t) {

NotifyHandlerException (ctx, t)

}

}

It's clear and easy to understand.

Then there is DefaultChannelHandlerInvoker.invokeChannelRead, with the following code:

@ Override

Public void invokeChannelRead (final ChannelHandlerContext ctx, final Object msg) {

If (msg = = null) {

Throw new NullPointerException ("msg")

}

If (executor.inEventLoop ()) {

InvokeChannelReadNow (ctx, msg)

} else {

SafeExecuteInbound (new Runnable () {

@ Override

Public void run () {

InvokeChannelReadNow (ctx, msg)

}

}, msg)

}

}

Executor.inEventLoop (), whether the executor of the current channel is in a time cycle, well, so far, I don't know when I will go into the else, so I have to find out later.

Go further, DefaultChannelHandlerContext.fireChannelRead, and the code is as follows:

Public ChannelHandlerContext fireChannelRead (Object msg) {

DefaultChannelHandlerContext next = findContextInbound (MASK_CHANNEL_READ)

Next.invoker.invokeChannelRead (next, msg)

Return this

}

The sequential execution of handler is reflected in this.

Go ahead, DefaultChannelPipeline.fireChannelRead, the code is as follows:

Public ChannelPipeline fireChannelRead (Object msg) {

Head.fireChannelRead (msg)

Return this

}

Well, if you remember correctly, when we first declared a netty, we added a series of handler to the channel pipeline. So how is this series of handler saved in pipeline? Let me first take a look at the constructor of DefaultChannelPipeline:

Public DefaultChannelPipeline (AbstractChannel channel) {

If (channel = = null) {

Throw new NullPointerException ("channel")

}

This.channel = channel

TailHandler tailHandler = new TailHandler ()

Tail = new DefaultChannelHandlerContext (this, null, generateName (tailHandler), tailHandler)

HeadHandler headHandler = new HeadHandler (channel.unsafe ())

Head = new DefaultChannelHandlerContext (this, null, generateName (headHandler), headHandler)

Head.next = tail

Tail.prev = head

}

First a tail and a head are born, and then the two objects are formed into a two-way linked list.

Take another look at the addlast method:

Private void addLast0 (final String name, DefaultChannelHandlerContext newCtx) {

CheckMultiplicity (newCtx)

DefaultChannelHandlerContext prev = tail.prev

NewCtx.prev = prev

NewCtx.next = tail

Prev.next = newCtx

Tail.prev = newCtx

Name2ctx.put (name, newCtx)

CallHandlerAdded (newCtx)

}

Clearly, insert an element in the linked list. Compare it with the previous code, starting with head, but it doesn't do the actual work, just take its next to execute, and then facilitate the linked list in turn.

At this point, the study of "what is the order of execution of netty handler" is over. I hope to be able to solve your doubts. The collocation of theory and practice can better help you learn, go and try it! If you want to continue to learn more related knowledge, please continue to follow the website, the editor will continue to work hard to bring you more practical articles!

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.