Dubbo 2.7.0的provider无法指定客户端默认async

[haiyang1985]

• I have searched the issues of this repository and believe that this is not a duplicate.
• I have checked the FAQ of this repository and believe that this is not a duplicate.

Environment

• Dubbo version: 2.7.0
• Operating System version: macOS Sierra 10.12
• Java version: 1.8.0_111

Steps to reproduce this issue

1. start provider and specific async as true, <dubbo:service interface="" async="true">
2. start consumer without async specific.
3. send a request

Pls. provide [GitHub address] to reproduce this issue.

Expected Result

What do you expected from the above steps？
We are able to get the value from the CompletableFuture.
service.sayHello(input);
CompletableFuture future = RpcContext.getContext().getCompletableFuture();
future.whenComplete((retValue, error) -> {
System.out.println(retValue);
});

Actual Result

What actually happens?
It throws NPE exception as following, as we are not able to get the future.
Exception in thread "main" java.lang.NullPointerException

With investigation, it's an issue in RegistryDirectory.
Also, we are able to get async=true from providerUrl, but the querymap's async is false from consumer side. It changed the async from true to false, and caused the issue.

private URL mergeUrl(URL providerUrl) {
providerUrl = ClusterUtils.mergeUrl(providerUrl, queryMap);
}

If there is an exception, please attach the exception trace:

Just put your stack trace here!

[carryxyh]

This is a normal result.
The asynchronous side of the server should of course not affect the client.

I don't think this is a problem. Do u have any questions about it?

[haiyang1985]

Once provider upgrade to 2.7.0, invoke be changed from async to sync, that means client cannot get result from context future.

Also, what will the async config for in provider side?

[carryxyh]

Once provider upgrade to 2.7.0, invoke be changed from async to sync

I don't get your point.. Why does upgrading to 2.7 change from synchronous to asynchronous?

Also, what will the async config for in provider side?

<dubbo:service interface="..." async="true"> is enough

[haiyang1985]

Provider 2.5.x, consumer 2.5.x, provider specific async, consumer keeps default.
<dubbo:service interface="..." async="true">
<dubbo:reference interface="...">

For consumer, they have to get value from RpcContext.
client.sayHello() returns null.
RpcContext.getContext.getFuture() returns value.

Provider 2.7.0, consumer 2.5.x, provider speicif async, consumer keeps default.
<dubbo:service interface="..." async="true">
<dubbo:reference interface="...">

For consumer, the value form RpcContext is null, this is incompatible.
client.sayHello() returns value.
RpcContext.getContext.getFuture() returns null.

[carryxyh]

Got it.

In the new version (2.7.x), the asynchronous of the provider and consumer is isolated. However, in the old version, consumer asynchronous and provider asynchronous are still bound.

Is this situation considered? @chickenlj Maybe it is a problem that we need to fix.

[haiyang1985]

Is provider async redundancy as we are able to return CompletableFuture?

It's sync for provider.
String sayHello(String msg);

It's async for provider.
Completable sayHello(String msg);

[chickenlj]

Is provider async redundancy as we are able to return CompletableFuture?

It's sync for provider.
String sayHello(String msg);

It's async for provider.
Completable sayHello(String msg);

AsyncContext is mainly designed for String sayHello(String msg);, to make sync methods being able to achieve async on provider side.

[chickenlj]

<dubbo:service interface="..." async="true">

Provider should not be configured to allow async, user should be able to decide they want async or sync when programming without any precondition, that's what Dubbo guaranteed now.

So I think what we should do is to remove async="true" property from <dubbo:service/>.

[haiyang1985]

For async, it's reasonable to remove it from dubbo:service/. But, are we going to remove timeout and retries also? Provider should be clear about the timeout and idempotency, then consumer. For these two keys should be kept, provider should have default values for consumer.

[fisherwangcn]

都是中国人在用，为啥总是说英文，散装英语不如直接写中文啊