public interface Filter
unified extension for replace old version extensions:
1. Handler
2. HttpClientFilter
3. HttpServerFilter
thread rule:
assume a producer filter chains is: f1, f2, schedule, f3, f4
schedule is a builtIn filter, which will dispatch invocations to operation related threadPool
f1 and f2 are before "schedule" filter, default to run in eventLoop
if developers customize filters and switch to other threads
it's better to switch back to eventLoop, unless you know what you are doing
f3 and f4 are after "schedule" filter, default thread depend on controller's method signature
1. if controller method not return CompletableFuture
then will run in a real threadPool
2. if controller method return CompletableFuture
then will still run in eventLoop
so filters after "schedule" filter, are more complex than filters before "schedule"
if developers need to do some BLOCK logic, MUST use different Strategy when running in different thread:
1. threadPool: run do BLOCK logic directly
2. eventLoop: MUST submit to a threadPool, and then switch back
(reactive golden rule)
| Modifier and Type | Method and Description |
|---|---|
default List<InvocationType> |
getInvocationTypes() |
default String |
getName() |
default boolean |
isEnabled() |
default boolean |
isInEventLoop() |
CompletableFuture<Response> |
onFilter(Invocation invocation,
FilterNode nextNode) |
default boolean isEnabled()
default boolean isInEventLoop()
@Nonnull default List<InvocationType> getInvocationTypes()
CompletableFuture<Response> onFilter(Invocation invocation, FilterNode nextNode)
invocation - invocationnextNode - node filter nodeCopyright © 2017–2022 The Apache Software Foundation. All rights reserved.