dubbo中的Filter顺序

最近发现dubbo的小 bug，顺便整理了一下dubbo中的Filter调用顺序及如何确定的。

服务提供方的过滤器被调用顺序：

EchoFilter->ClassLoaderFilter->GenericFilter->ContextFilter->(这4个是在代码中指定的)

ExceptionFilter->  TimeoutFilter ->MonitorFilter-> TraceFilter

服务消费方的过滤器顺序：

ConsumerContextFilter->FutureFilter->MonitorFilter

负责加载过滤器的类

ProtocolFilterWrapper

 

这个顺序和SPI配置文件的顺序并不一致。那么是什么决定了Filter的顺序呢？

通过查看源代码可以看到，在初始化Filter时，有一个对所有的过滤器排序的过程，其使用的比较类是ActivateComparator。在这个类中，可以看到，是使用Filter中的Activate类进行排序的。而 Activate注解中，有一个order的属性，这个属性指定了Filter在chain中的顺序。

通过查看EchoFilter的Activate属性，可以看到其order = -110000，而ClassLoaderFilter的order=-30000,因此可以断定，order值越小，其越位于调用端的最顶层。那么当order相同时（都没有设置时），又是根据什么排序的呢？

Collections.sort算法

从其说明文档可以看出，这个算法是一个稳定的排序算法，如果两个值相同，不会改变其前后顺序。并且从其文档可以看出，其所使用的是一个修改过的归并排序算法。

但是 Activate的compare方法故意将两个相同的order类弄成了不同，导致排序有些变化。造成了最终上述顺序。

所以导致原来配置文件中的位置为：

1、monitor 

2、trace

3、exception

4、timeout

排序后变成了

1、 exception

2、timeout

3、monitor

4、trace

 

文章链接： http://donlianli.com/?p=36