码迷,mamicode.com
首页 > Web开发 > 详细

Netty in Action (十六) 第六章节 第二部分 ChannelHandlerContext和异常处理

时间:2016-04-29 19:08:56      阅读:274      评论:0      收藏:0      [点我收藏+]

标签:

6.3 Interface ChannelHandlerContext


一个ChannelHandlerContext代表了一个ChannelHandler和ChannelPipeline之间的关系,ChannelHandlerContext创建于ChannelHandler被载入到ChannelPipeline的时候,ChannelHandlerContext主要功能是管理在同一ChannelPipeline中各个ChannelHandler的交互


ChannelHandlerContext有很多方法,其中的一些方法也出现在Channel和ChannelPipeline中,但是相同的方法却有一些不同的效果,如果你在Channel或者在ChannelPipeline实例中实现这些方法,它们会传播到整个管道,同样的方法如果被ChannelHandlerContext执行的时候,那么它会在当前关联的ChannelHandler中开始执行,然后只会传播到管道中符合条件(符合方向的有兴趣的)的下一个ChannelHandler处理


表6.10总结了ChannelHandlerContext的APIs

技术分享

技术分享

当你使用ChannelHandlerContext的时候,请牢记以下几点原则:

1)与ChannelHandlerContext关联的ChannelHandler是不会改变的,所以如果对其引用做一份缓存是安全的

2)ChannelHandlerContext的方法与定义在其他class中的方法是不一样的,它有着较短的生命周期,这个可以被用来尽可能的提高应用的性能


6.3.1 Using ChannelHandlerContext


在这个小节中,我们将讨论如何使用ChannelHandlerContext并且查看由ChannelHandlerContext,Channel,ChannelPipeline提供的一些方法,图6.4向你展示了它们三者之间的关系

技术分享

在下面的代码清单中,你将从ChannelHandlerContext中获取一个Channel的引用,通过调用Channel的write的方法写在管道里会引起一个写入流

技术分享

下面的代码清单也展示了一个相似的例子,这次也是用ChannelPipeline写入,我们可以从ChannelHandlerContext中获取的ChannelPipeline引用


技术分享

代码清单6.6和代码清单6.7是很相似的,都如图6.5所示,你必须注意到通过Channel或者ChannelPipeline调用write方法都会使事件沿着管道传播,这一点是很重要的,从一个Channel到下一个Channel的移动是由ChannelHandlerContext管控的

技术分享

为什么有时候我们需要在ChannelPipeline中的某些具体的地方开始传播一个事件呢?

1)减少事件在那些对该事件不感兴趣的处理器传播的损耗

2)防止那些“感兴趣”的处理器处理后产生不好的影响


为了从一个指定的ChannelHandler开始执行处理,你必须指定一个ChannelHandler处理器之前的那个ChannelHandlerContext,这个ChannelHandlerContext会调用与它关联的那个ChannelHandler,这个ChannelHandler也就是我们指定的那个处理器


下面的代码清单和图6.6说明了这个使用的方法

技术分享

如图6.6所示,信息从图中第二个ChannelHandler中开始在ChannelPipeline中传播,跳过了前一个


我们刚才描述使用的是一个很常见的一种使用方式,调用一个特定的ChannelHandler实例是一个非常有用的操作方式


技术分享

6.3.2 Advanced uses of ChannelHandler and ChannelHandlerContext


在我们之前看见的6.6清单所示,我们通过ChannelHandlerContext的pipeline方法获取到一个ChannelPipeline的引用,这里可以在运行的时候操作管道中的ChannelHandler,这里可以在复杂的业务场景中用到,例如,你可以通过增加一个ChannelHandler到管道中来支持动态协议的改变


另一个使用的好处就是获取一个ChannelHandlerContext的一个引用,这个引用的缓存可以支持“延迟使用”,这样可以发生在ChannelHandler之外甚至可以给不同的线程都执行,下面的代码清单展示了这种模式

技术分享

因为一个ChannelHandler可以属于多个ChannelPipeline,它也可以绑定多个ChannelHandlerContext实例,如果一个ChannelHandler想要有这样的功能,就必须以@Sharable注解注释这个ChannelHandler,否则,尝试将其加入到不止一个ChannelPipeline中去的时候,会报出异常,很明显,使用这样的支持多线程的channel你必须保证该类是线程安全的,无状态的


下面的代码清单展示了这个模式一个正确的实现

技术分享

先前的ChannelHandler实现了满足其被在多个管道使用时的多个需求,顾名思义,它被@Sharable注解了自己,并且它不包含任何的状态,相反,下面的6.11代码清单就可能引起一些问题:

技术分享

这个代码的问题是因为它是有状态的,因为有一个count的变量,这个变量会计算该方法的调用,增加这个类的实例到ChannelPipeline中去就可能会出现错误,当它被并发的channel触发的时候出现


总而言之,你必须保证你的ChannelHandler是线程安全的在你使用@Sharable的时候

WHY SHARE A CHANNELHANDLER? 在多个ChannelPipeline中使用同一个ChannelHandler的一个正常理由是多个Channel的统计信息


我们对ChannelHandlerContext的讨论做了总结,并且讲解了它与其他组件之间的关系,下一个小节,我们讨论一下异常处理


6.4 Exception handling


异常处理对于任意一个重大的系统都是一个很重要的模块,它可以以多种方式去完成这个模块,相应的,Netty提供了一些输入输出处理时产生异常的一些处理选项,这个小节将帮助你理解这些方式,并找出最合适满足你需要的处理方式


6.4.1 Handling inbound exceptions

在输入事件处理过程中一个异常抛出时,这个异常将会在触发该异常的ChannelInboundHandler的地方开始在ChannelPipeline传播,为了处理这样的异常,你需要在你的ChannelPipeline实现中重写如下的方法

技术分享


下面的代码清单向你展示一个简单的异常处理例子:关闭channel然后打印出异常信息

技术分享

因为发生的异常可以继续沿着输入的方向传播,这就保证了无论异常在哪里发生,所有在ChannelPipeline中的业务逻辑都会处理,且所有的异常都会被捕获处理


关于如何处理异常更多的情况下是取决你具体的应用程序,你可能会关闭channel连接,也可能去尝试去恢复,当然,如果你没有实现任何异常处理的方法,Netty将会记录异常没有被处理


总结如下:

1)默认的ChannelHandler的exceptionCaught的实现会把异常传给管道中的下一个处理器

2)如果一个异常到达了一个管道的结尾,它将被记录为未被处理

3)来定义自定义的处理,你重写了exceptionCaught方法,这将是你自己的决定你是否决定将其接着传播到下游处理器


6.4.2 Handling outbound exceptions


处理输出操作的正常实现或者异常问题是基于以下几点列出的机制:

1)每一个输出操作返回一个ChannelFuture,注册到ChannelFuture上的ChannelFutureListener会被通知操作是否成功或者失败当操作完成的时候

2)几乎所有的ChannelOutboundHandler都会传递一个ChannelPromise实例,作为ChannelFuture的子类,它也可以被监听器管控来获取异步通知,但是ChannelPromise为实时通知提供可写的方法


技术分享

在ChannelFuture实例中增加一个ChannelFutureListener是为了调用addListener方法,有两种方法可以完成这个实现,一个最最常用的方式是调用由输出操作返回的ChannelFuture的addListener方法

下面的代码清单使用了这个方法来增加一个ChannelFutureListener,用来打印一次然后关闭Channel

技术分享

第二个方式是通过在ChannelOutboundHandler方法中作为参数的传递的ChannelPromise增加一个ChannelFutureListener,下面的代码清单展示了与上面代码有相同功能的实现

技术分享

技术分享

TIPS:ChannelPromise的写方法

通过调用ChannelPromise的setSuccess或者setFailure方法,你可以是调用者在ChannelHandler返回的时候,立马知道操作的是否成功


怎么才知道两个方式哪个更好呢?如果你想要更仔细地处理异常,那么你会发现使用代码清单6.13中更加合适,但是如果你想更加专业的处理异常,你会发现6.14显得更加简单


如果ChannelOutboundHandler自己本身发生了异常,那么会发生什么呢?这种情况下,Netty本身会通知注册到相对应的ChannelPromise上的任意监听器


6.5 Summary

在这个章节,我们讨论了Netty的数据处理组件ChannelHandler,我们讨论了多个ChannelHandler链在一起,讨论了ChannelInboundHandler和ChannelOutboundHandler如何与ChannelPipeline交互的


下一个章节我们讨论Netty的编码抽象,这个将比直接使用底层的ChannelHandler实现来编写编码和解码更加简单



Netty in Action (十六) 第六章节 第二部分 ChannelHandlerContext和异常处理

标签:

原文地址:http://blog.csdn.net/linuu/article/details/51160335

(0)
(0)
   
举报
评论 一句话评论(0
登录后才能评论!
© 2014 mamicode.com 版权所有  联系我们:gaon5@hotmail.com
迷上了代码!