You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@dubbo.apache.org by yuhang xiu <ca...@gmail.com> on 2018/09/05 07:29:57 UTC

The effect of Provider async on the Consumer side

Hi community,

Recently I found a bug[1] in the issue list (submitted by the
https://github.com/fingthinking user), which has been verified to be valid.
The root cause of the problem is that the Provider registered the
method.async to the registry and finally affected the Consumer side.

The user submitted pr[2] to fix the problem. The fix is that the provider
does not register the method.async to the registry, so the Consumer side
cannot perceive it.
I think this way is not the best. I think the best way is that the Provider
side still registers method.async to the registry, but the Consumer side
ignores this property. The advantage is that in the future we can still see
the asynchronous situation of the various methods of the provider on
dubbo-ops, and this processing method is more in line with the purpose of
dubbo configuration coverage.

What do you think about it?

[1]https://github.com/apache/incubator-dubbo/issues/2321
[2]https://github.com/apache/incubator-dubbo/pull/2322

Re: The effect of Provider async on the Consumer side

Posted by yuhang xiu <ca...@gmail.com>.
Hi, community,
After checking the code and discussion, I think it would be better if you
fix this problem at both ends.

1. On the Provider side, the method.async is not exposed to ensure
compatibility.
2. Ignore the Provider's method.async property on the Consumer side to
ensure that the Provider's method.async does not affect the Consumer's
behavior.

In the future, when OPS shows the asynchronous situation of the provider,
we just need to let the provider still register the method.async property.

ISSUE is here, there are some discussion, too:
https://github.com/apache/incubator-dubbo/issues/2321

Huxing Zhang <hu...@apache.org> 于2018年9月12日周三 上午9:46写道:

> On Mon, Sep 10, 2018 at 10:10 AM yuhang xiu <ca...@gmail.com> wrote:
> >
> > Hi Huxing,
> > This is because there is a bug that causes them to be inconsistent. We
> > removed the async attribute from the Provider in ClusterUtil, but did not
> > remove the method.async attribute, causing the Provider's method.async to
> > affect the Consumer side.
> >
> > We don't need extra configuration, we just need to remove method.async in
> > ClusterUtil to solve this problem, and we don't need to modify the URL of
> > the Provider registered in the registry.
>
>
> Thanks for the explanation, it looks good to me!
>
> >
> > Huxing Zhang <hu...@apache.org> 于2018年9月7日周五 下午11:40写道:
> >
> > > Hi,
> > >
> > > On Wed, Sep 5, 2018 at 3:30 PM yuhang xiu <ca...@gmail.com> wrote:
> > > >
> > > > Hi community,
> > > >
> > > > Recently I found a bug[1] in the issue list (submitted by the
> > > > https://github.com/fingthinking user), which has been verified to be
> > > valid.
> > > > The root cause of the problem is that the Provider registered the
> > > > method.async to the registry and finally affected the Consumer side.
> > > >
> > > > The user submitted pr[2] to fix the problem. The fix is that the
> provider
> > > > does not register the method.async to the registry, so the Consumer
> side
> > > > cannot perceive it.
> > > > I think this way is not the best. I think the best way is that the
> > > Provider
> > > > side still registers method.async to the registry, but the Consumer
> side
> > > > ignores this property.
> > >
> > > Do you have any idea how to achieve this? Do we need to have extra
> > > configuration on consumer side?
> > > Or is it a special case?
> > >
> > > > The advantage is that in the future we can still see
> > > > the asynchronous situation of the various methods of the provider on
> > > > dubbo-ops,
> > >
> > > +1
> > >
> > > > and this processing method is more in line with the purpose of
> > > > dubbo configuration coverage.
> > > >
> > > > What do you think about it?
> > > >
> > > > [1]https://github.com/apache/incubator-dubbo/issues/2321
> > > > [2]https://github.com/apache/incubator-dubbo/pull/2322
> > >
> > > I also noticed that you have replied on the issue:
> > >
> > > > When using <dubbo:service async="true" .../>, the Consumer will not
> be
> > > affected. However, the Consumer call will be affected when using
> > > <dubbo:method name="sayHello" async="true"/>.
> > >
> > > Why they are not consistent?
> > >
> > > --
> > > Best Regards!
> > > Huxing
> > >
>
>
>
> --
> Best Regards!
> Huxing
>

Re: The effect of Provider async on the Consumer side

Posted by Huxing Zhang <hu...@apache.org>.
On Mon, Sep 10, 2018 at 10:10 AM yuhang xiu <ca...@gmail.com> wrote:
>
> Hi Huxing,
> This is because there is a bug that causes them to be inconsistent. We
> removed the async attribute from the Provider in ClusterUtil, but did not
> remove the method.async attribute, causing the Provider's method.async to
> affect the Consumer side.
>
> We don't need extra configuration, we just need to remove method.async in
> ClusterUtil to solve this problem, and we don't need to modify the URL of
> the Provider registered in the registry.


Thanks for the explanation, it looks good to me!

>
> Huxing Zhang <hu...@apache.org> 于2018年9月7日周五 下午11:40写道:
>
> > Hi,
> >
> > On Wed, Sep 5, 2018 at 3:30 PM yuhang xiu <ca...@gmail.com> wrote:
> > >
> > > Hi community,
> > >
> > > Recently I found a bug[1] in the issue list (submitted by the
> > > https://github.com/fingthinking user), which has been verified to be
> > valid.
> > > The root cause of the problem is that the Provider registered the
> > > method.async to the registry and finally affected the Consumer side.
> > >
> > > The user submitted pr[2] to fix the problem. The fix is that the provider
> > > does not register the method.async to the registry, so the Consumer side
> > > cannot perceive it.
> > > I think this way is not the best. I think the best way is that the
> > Provider
> > > side still registers method.async to the registry, but the Consumer side
> > > ignores this property.
> >
> > Do you have any idea how to achieve this? Do we need to have extra
> > configuration on consumer side?
> > Or is it a special case?
> >
> > > The advantage is that in the future we can still see
> > > the asynchronous situation of the various methods of the provider on
> > > dubbo-ops,
> >
> > +1
> >
> > > and this processing method is more in line with the purpose of
> > > dubbo configuration coverage.
> > >
> > > What do you think about it?
> > >
> > > [1]https://github.com/apache/incubator-dubbo/issues/2321
> > > [2]https://github.com/apache/incubator-dubbo/pull/2322
> >
> > I also noticed that you have replied on the issue:
> >
> > > When using <dubbo:service async="true" .../>, the Consumer will not be
> > affected. However, the Consumer call will be affected when using
> > <dubbo:method name="sayHello" async="true"/>.
> >
> > Why they are not consistent?
> >
> > --
> > Best Regards!
> > Huxing
> >



-- 
Best Regards!
Huxing

Re: The effect of Provider async on the Consumer side

Posted by yuhang xiu <ca...@gmail.com>.
Hi Huxing,
This is because there is a bug that causes them to be inconsistent. We
removed the async attribute from the Provider in ClusterUtil, but did not
remove the method.async attribute, causing the Provider's method.async to
affect the Consumer side.

We don't need extra configuration, we just need to remove method.async in
ClusterUtil to solve this problem, and we don't need to modify the URL of
the Provider registered in the registry.

Huxing Zhang <hu...@apache.org> 于2018年9月7日周五 下午11:40写道:

> Hi,
>
> On Wed, Sep 5, 2018 at 3:30 PM yuhang xiu <ca...@gmail.com> wrote:
> >
> > Hi community,
> >
> > Recently I found a bug[1] in the issue list (submitted by the
> > https://github.com/fingthinking user), which has been verified to be
> valid.
> > The root cause of the problem is that the Provider registered the
> > method.async to the registry and finally affected the Consumer side.
> >
> > The user submitted pr[2] to fix the problem. The fix is that the provider
> > does not register the method.async to the registry, so the Consumer side
> > cannot perceive it.
> > I think this way is not the best. I think the best way is that the
> Provider
> > side still registers method.async to the registry, but the Consumer side
> > ignores this property.
>
> Do you have any idea how to achieve this? Do we need to have extra
> configuration on consumer side?
> Or is it a special case?
>
> > The advantage is that in the future we can still see
> > the asynchronous situation of the various methods of the provider on
> > dubbo-ops,
>
> +1
>
> > and this processing method is more in line with the purpose of
> > dubbo configuration coverage.
> >
> > What do you think about it?
> >
> > [1]https://github.com/apache/incubator-dubbo/issues/2321
> > [2]https://github.com/apache/incubator-dubbo/pull/2322
>
> I also noticed that you have replied on the issue:
>
> > When using <dubbo:service async="true" .../>, the Consumer will not be
> affected. However, the Consumer call will be affected when using
> <dubbo:method name="sayHello" async="true"/>.
>
> Why they are not consistent?
>
> --
> Best Regards!
> Huxing
>

Re: The effect of Provider async on the Consumer side

Posted by Huxing Zhang <hu...@apache.org>.
Hi,

On Wed, Sep 5, 2018 at 3:30 PM yuhang xiu <ca...@gmail.com> wrote:
>
> Hi community,
>
> Recently I found a bug[1] in the issue list (submitted by the
> https://github.com/fingthinking user), which has been verified to be valid.
> The root cause of the problem is that the Provider registered the
> method.async to the registry and finally affected the Consumer side.
>
> The user submitted pr[2] to fix the problem. The fix is that the provider
> does not register the method.async to the registry, so the Consumer side
> cannot perceive it.
> I think this way is not the best. I think the best way is that the Provider
> side still registers method.async to the registry, but the Consumer side
> ignores this property.

Do you have any idea how to achieve this? Do we need to have extra
configuration on consumer side?
Or is it a special case?

> The advantage is that in the future we can still see
> the asynchronous situation of the various methods of the provider on
> dubbo-ops,

+1

> and this processing method is more in line with the purpose of
> dubbo configuration coverage.
>
> What do you think about it?
>
> [1]https://github.com/apache/incubator-dubbo/issues/2321
> [2]https://github.com/apache/incubator-dubbo/pull/2322

I also noticed that you have replied on the issue:

> When using <dubbo:service async="true" .../>, the Consumer will not be affected. However, the Consumer call will be affected when using <dubbo:method name="sayHello" async="true"/>.

Why they are not consistent?

-- 
Best Regards!
Huxing