Issue 1:
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

Operating System version:

Java version: 1.8

Steps to reproduce this issue

正常导出服务，服务提供者地址为http://169.254.71.3:8081/com.luban.mock_demo.api.HelloService?anyhost=true&application=xml-demo-provider&bean.name=com.luban.mock_demo.api.HelloService&bind.ip=169.254.71.3&bind.port=8081&default.deprecated=false&default.dynamic=false&default.register=true&deprecated=false&dubbo=2.0.2&dynamic=false&generic=false&interface=com.luban.mock_demo.api.HelloService&methods=sayHello&pid=15854&register=true&release=2.7.0&server=tomcat&side=provider&timeout=2000&timestamp=1553146018199

修改改服务的动态配置后，服务提供者地址变为http://169.254.71.3:8081/com.luban.mock_demo.api.HelloService?anyhost=true&application=xml-demo-provider&bean.name=com.luban.mock_demo.api.HelloService&bind.ip=169.254.71.3&bind.port=8081&compatible_config=true&default.deprecated=false&default.dynamic=false&default.register=true&deprecated=false&dubbo=2.0.2&dynamic=false&generic=false&interface=com.luban.mock_demo.api.HelloService&methods=sayHello&pid=15854&register=true&release=2.7.0&server=tomcat&side=provider&timeout=6000&timestamp=1553146018199，该地址中增加了参数compatible_config=true。

消费引用服务报找不到服务提供者地址。

问题出现的原因其实就是因为新的服务提供者地址中增加了compatible_config=true参数，消费者在引入该服务时，改地址会被过滤掉，所以找不到该服务提供者地址。

而compatible_config=true该参数出现的原因是，修改了动态配置中心，所以在configurators中存在了override%3A%2F%2F0.0.0.0%2Fcom.luban.mock_demo.api.HelloService%3Fcategory%3Dconfigurators%26compatible_config%3Dtrue%26dynamic%3Dfalse%26enabled%3Dtrue%26timeout%3D6000，这个地址中有compatible_config参数，并且服务端会监听到这个地址的变化，然后去重写服务提供者地址，就导致了服务提供者地址中出现compatible_config=true参数。

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

Expected Result

消费能正常引用改服务

Actual Result

消费不能正常引用改服务

What actually happens?

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

Just put your stack trace here!

Issue 2:
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.

Confusion

Are there a feature for batched rpc in dubbo?

what I mean batched rpc is that the individual invocations in a batch are dispatched by a single thread in server-side in the order in which they were placed into the batch message, which guarantees the individual operations in a batched rpc are processed in order in the server.

the official-site-doc says we can set up retry-timeout in an xml file and then the client will retry all the failed invocations regardless what's failing the invocation.

Does the Dubbo follow at-most-once semantics when handling failures?

How does Dubbo handle failed invocations in the following cases:

A connection could not be established due to the crash of the remote physical machine (connection unreachable error)

A connection could not be established due to the crash of the remote process (connection refused error)

A connection lost due to the accident shutdown of the remote physical machine (connection unreachable error)

A connection lost due to the crash of the remote process (connection refused error)

An remote invocation timeout expired due to software bug such as thread overflowed, deadlock or high cpu loads, oom.

An exception occurred while sending the request

An exception occurred while receiving the reply

An exception occurred after sending the request

An exception occurred after receiving the reply

where abcde are the failure cases and fghi are the state of the system when error happens.

that means we have 20 combinations that need to take into account...

Regards,

Thanks.