最近发现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