[DISCUSSION] Make filter totally asynchronous and event-driven.

[chickenlj]

Recently, I am thinking of making the whole invoker chain inside Dubbo asynchronous, event-driven. And I believe that Filter can be changed to better adapt to the new model.

Before 2.7.0, you can find the definition of Filter was completely synchronous:

public interface Filter {
    Result invoke(Invoker<?> invoker, Invocation invocation) throws RpcException {
       // before
        Result result = invoker.invoke(invocation);
       // after
      return result;
    }
}

In 2.7.0, a callback onResponse was added to allow users to handle the async value when result returns.

public interface Filter {
   Result invoke(Invoker<?> invoker, Invocation invocation) throws RpcException {
   }

   void onResponse(Result result, Invoker<?> invoker, Invocation invocation) {
        // biz return
    }
}

Now, how about the following definition, totally asynchronous and event-driven?

public interface Filter {
   void onSend(Invocation invocation) {
     // before invoke, throw exception to terminate 
    }

   void onResponse(Result result, Invoker<?> invoker, Invocation invocation) {
        // biz return successfully
    }

   void onError(Throwable e) throws RpcException{
        // biz throw exception
    }
}

[carryxyh]

good idea. But I want to remind that in onError we still need some information other than Throwable, such as invocation and result.

[carryxyh]

@chickenlj
If we can reach a consensus, can you let me try it?
:)

[chickenlj]

@carryxyh Let's wait to hear more voices.

[carryxyh]

About compatibility issues.

The current version will enter onResponse due to all requests (correct or incorrect). If we modify the code, the correct response enters onResponse, the error response enters onError, and onResponse will only process the correct request if the user does not modify the Filter code.

Is this a problem that we should consider?

[chickenlj]

Bringing Ian's question to here:

In your new proposed interface, how could we construct a filter chain? Say,
how could filter-a process further a value processed by filter-b?

I don't think we still need a nested Filter chain as before, the new Filter can simply work as follow:

Iterate(filters) {
    filter.onSend();
}

Result result = invoker.invoke();

result.whenComplete((value, t) {
  Iterate tail-to-head(filters) {
     filter.doResponse();
     filter.doError();
  }
});

[CrazyHZM]

Already achieved.