You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@dubbo.apache.org by jun liu <ke...@gmail.com> on 2019/03/01 09:44:52 UTC
[DISCUSSION] Idea about making Filter totally asynchronous and
event-driven.
Hi,
I am thinking of the possibility of changing the current Filter definition model to make it totally asynchronous and event-driven. Here’s the detailed proposal[1]. It’s only a immature idea at present so I am not sure fi it’s good to have this change yet, especially from the user’s side.
In short, the new Filter would look like:
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
}
}
1. https://github.com/apache/incubator-dubbo/issues/3585
Jun
Re: [DISCUSSION] Idea about making Filter totally asynchronous and
event-driven.
Posted by jun liu <ke...@gmail.com>.
> In your new proposed interface, how could we construct a filter chain?
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();
}
});
Jun
> On Mar 3, 2019, at 10:41 PM, Ian Luo <ia...@gmail.com> wrote:
>
> Jun,
>
> 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?
>
> Thanks,
> -Ian.
>
>
> On Fri, Mar 1, 2019 at 5:44 PM jun liu <ke...@gmail.com> wrote:
>
>> Hi,
>>
>> I am thinking of the possibility of changing the current Filter definition
>> model to make it totally asynchronous and event-driven. Here’s the detailed
>> proposal[1]. It’s only a immature idea at present so I am not sure fi it’s
>> good to have this change yet, especially from the user’s side.
>>
>> In short, the new Filter would look like:
>>
>> 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
>> }
>> }
>>
>> 1. https://github.com/apache/incubator-dubbo/issues/3585
>>
>> Jun
>>
>>
Re: [DISCUSSION] Idea about making Filter totally asynchronous and event-driven.
Posted by Ian Luo <ia...@gmail.com>.
yes, backward compatibility is definitely another issue we should think
about.
-Ian.
On Mon, Mar 4, 2019 at 12:18 PM yuhang xiu <ca...@gmail.com> wrote:
> Hi,
>
> 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?
>
> Ian Luo <ia...@gmail.com> 于2019年3月3日周日 下午10:49写道：
>
> > Jun,
> >
> > 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?
> >
> > Thanks,
> > -Ian.
> >
> >
> > On Fri, Mar 1, 2019 at 5:44 PM jun liu <ke...@gmail.com> wrote:
> >
> > > Hi,
> > >
> > > I am thinking of the possibility of changing the current Filter
> > definition
> > > model to make it totally asynchronous and event-driven. Here’s the
> > detailed
> > > proposal[1]. It’s only a immature idea at present so I am not sure fi
> > it’s
> > > good to have this change yet, especially from the user’s side.
> > >
> > > In short, the new Filter would look like:
> > >
> > > 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
> > > }
> > > }
> > >
> > > 1. https://github.com/apache/incubator-dubbo/issues/3585
> > >
> > > Jun
> > >
> > >
> >
>
Re: [DISCUSSION] Idea about making Filter totally asynchronous and
event-driven.
Posted by jun liu <ke...@gmail.com>.
For legacy filter implementations with all logic inside “invoke()”, compatibility would be a problem. I am not thinking of it yet.
Jun
> On Mar 4, 2019, at 6:49 PM, Ian Luo <ia...@gmail.com> wrote:
>
> Jun,
>
> The method signature is totally different. Are you indicating a default
> bridge method to address this particular concern?
>
> Thanks,
> -Ian.
>
>
> On Mon, Mar 4, 2019 at 4:44 PM jun liu <ke...@gmail.com> wrote:
>
>>> 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.
>>
>> For legacy filters only implement onResponse, I think we can solve this by
>> redirecting onError to onResponse by default.
>>
>> Jun
>>
>>> On Mar 4, 2019, at 11:53 AM, yuhang xiu <ca...@gmail.com> wrote:
>>>
>>> Hi,
>>>
>>> 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?
>>>
>>> Ian Luo <ia...@gmail.com> 于2019年3月3日周日 下午10:49写道：
>>>
>>>> Jun,
>>>>
>>>> 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?
>>>>
>>>> Thanks,
>>>> -Ian.
>>>>
>>>>
>>>> On Fri, Mar 1, 2019 at 5:44 PM jun liu <ke...@gmail.com> wrote:
>>>>
>>>>> Hi,
>>>>>
>>>>> I am thinking of the possibility of changing the current Filter
>>>> definition
>>>>> model to make it totally asynchronous and event-driven. Here’s the
>>>> detailed
>>>>> proposal[1]. It’s only a immature idea at present so I am not sure fi
>>>> it’s
>>>>> good to have this change yet, especially from the user’s side.
>>>>>
>>>>> In short, the new Filter would look like:
>>>>>
>>>>> 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
>>>>> }
>>>>> }
>>>>>
>>>>> 1. https://github.com/apache/incubator-dubbo/issues/3585
>>>>>
>>>>> Jun
>>>>>
>>>>>
>>>>
>>
>>
Re: [DISCUSSION] Idea about making Filter totally asynchronous and event-driven.
Posted by Ian Luo <ia...@gmail.com>.
Jun,
The method signature is totally different. Are you indicating a default
bridge method to address this particular concern?
Thanks,
-Ian.
On Mon, Mar 4, 2019 at 4:44 PM jun liu <ke...@gmail.com> wrote:
> > 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.
>
> For legacy filters only implement onResponse, I think we can solve this by
> redirecting onError to onResponse by default.
>
> Jun
>
> > On Mar 4, 2019, at 11:53 AM, yuhang xiu <ca...@gmail.com> wrote:
> >
> > Hi,
> >
> > 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?
> >
> > Ian Luo <ia...@gmail.com> 于2019年3月3日周日 下午10:49写道：
> >
> >> Jun,
> >>
> >> 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?
> >>
> >> Thanks,
> >> -Ian.
> >>
> >>
> >> On Fri, Mar 1, 2019 at 5:44 PM jun liu <ke...@gmail.com> wrote:
> >>
> >>> Hi,
> >>>
> >>> I am thinking of the possibility of changing the current Filter
> >> definition
> >>> model to make it totally asynchronous and event-driven. Here’s the
> >> detailed
> >>> proposal[1]. It’s only a immature idea at present so I am not sure fi
> >> it’s
> >>> good to have this change yet, especially from the user’s side.
> >>>
> >>> In short, the new Filter would look like:
> >>>
> >>> 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
> >>> }
> >>> }
> >>>
> >>> 1. https://github.com/apache/incubator-dubbo/issues/3585
> >>>
> >>> Jun
> >>>
> >>>
> >>
>
>
Re: [DISCUSSION] Idea about making Filter totally asynchronous and
event-driven.
Posted by jun liu <ke...@gmail.com>.
> 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.
For legacy filters only implement onResponse, I think we can solve this by redirecting onError to onResponse by default.
Jun
> On Mar 4, 2019, at 11:53 AM, yuhang xiu <ca...@gmail.com> wrote:
>
> Hi,
>
> 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?
>
> Ian Luo <ia...@gmail.com> 于2019年3月3日周日 下午10:49写道：
>
>> Jun,
>>
>> 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?
>>
>> Thanks,
>> -Ian.
>>
>>
>> On Fri, Mar 1, 2019 at 5:44 PM jun liu <ke...@gmail.com> wrote:
>>
>>> Hi,
>>>
>>> I am thinking of the possibility of changing the current Filter
>> definition
>>> model to make it totally asynchronous and event-driven. Here’s the
>> detailed
>>> proposal[1]. It’s only a immature idea at present so I am not sure fi
>> it’s
>>> good to have this change yet, especially from the user’s side.
>>>
>>> In short, the new Filter would look like:
>>>
>>> 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
>>> }
>>> }
>>>
>>> 1. https://github.com/apache/incubator-dubbo/issues/3585
>>>
>>> Jun
>>>
>>>
>>
Re: [DISCUSSION] Idea about making Filter totally asynchronous and event-driven.
Posted by yuhang xiu <ca...@gmail.com>.
Hi,
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?
Ian Luo <ia...@gmail.com> 于2019年3月3日周日 下午10:49写道：
> Jun,
>
> 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?
>
> Thanks,
> -Ian.
>
>
> On Fri, Mar 1, 2019 at 5:44 PM jun liu <ke...@gmail.com> wrote:
>
> > Hi,
> >
> > I am thinking of the possibility of changing the current Filter
> definition
> > model to make it totally asynchronous and event-driven. Here’s the
> detailed
> > proposal[1]. It’s only a immature idea at present so I am not sure fi
> it’s
> > good to have this change yet, especially from the user’s side.
> >
> > In short, the new Filter would look like:
> >
> > 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
> > }
> > }
> >
> > 1. https://github.com/apache/incubator-dubbo/issues/3585
> >
> > Jun
> >
> >
>
Re: [DISCUSSION] Idea about making Filter totally asynchronous and event-driven.
Posted by Ian Luo <ia...@gmail.com>.
Jun,
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?
Thanks,
-Ian.
On Fri, Mar 1, 2019 at 5:44 PM jun liu <ke...@gmail.com> wrote:
> Hi,
>
> I am thinking of the possibility of changing the current Filter definition
> model to make it totally asynchronous and event-driven. Here’s the detailed
> proposal[1]. It’s only a immature idea at present so I am not sure fi it’s
> good to have this change yet, especially from the user’s side.
>
> In short, the new Filter would look like:
>
> 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
> }
> }
>
> 1. https://github.com/apache/incubator-dubbo/issues/3585
>
> Jun
>
>