Package org.apache.dubbo.rpc

Interface Filter

All Superinterfaces:
BaseFilter
All Known Implementing Classes:
AccessLogFilter, ActiveLimitFilter, AdaptiveLoadBalanceFilter, ClassLoaderCallbackFilter, ClassLoaderFilter, CompatibleFilter, ContextFilter, DeprecatedFilter, EchoFilter, ExceptionFilter, ExecuteLimitFilter, GenericFilter, GenericImplFilter, ListenableFilter, ProfilerServerFilter, RpcExceptionFilter, TimeoutFilter, TokenFilter, TpsLimitFilter
@SPI(scope=MODULE) public interface Filter extends BaseFilter
Extension for intercepting the invocation for both service provider and consumer, furthermore, most of functions in dubbo are implemented base on the same mechanism. Since every time when remote method is invoked, the filter extensions will be executed too, the corresponding penalty should be considered before more filters are added. 
  They way filter work from sequence point of view is
    
    ...code before filter ...
          invoker.invoke(invocation) //filter work in a filter implementation class
          ...code after filter ...
    
    Caching is implemented in dubbo using filter approach. If cache is configured for invocation then before
    remote call configured caching type's (e.g. Thread Local, JCache etc) implementation invoke method gets called.
Starting from 3.0, Filter on consumer side has been refactored. There are two different kinds of Filters working at different stages of an RPC request. 1. Filter. Works at the instance level, each Filter is bond to one specific Provider instance(invoker). 2. ClusterFilter. Newly introduced in 3.0, intercepts request before Loadbalancer picks one specific Filter(Invoker). Filter Chain in 3.x -> Filter -> Invoker Proxy -> ClusterFilter -> ClusterInvoker -> Filter -> Invoker -> Filter -> Invoker Filter Chain in 2.x Filter -> Invoker Proxy -> ClusterInvoker -> Filter -> Invoker Filter -> Invoker Filter. (SPI, Singleton, ThreadSafe)
See Also: