You are viewing a plain text version of this content. The canonical link for it is here.
Posted to notifications@dubbo.apache.org by "Kiddinglife (GitHub)" <gi...@apache.org> on 2019/01/12 23:30:36 UTC
[GitHub] [incubator-dubbo] Kiddinglife opened issue #3215: How Dubbo
handles the failed RPC Invocation with different failing reasons?
- [ ] I have searched the [issues](https://github.com/apache/incubator-dubbo/issues) of this repository and believe that this is not a duplicate.
- [ ] I have checked the [FAQ](https://github.com/apache/incubator-dubbo/blob/master/FAQ.md) 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 batched rpc invocation 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.
- How does Dubbo failed invocations in the following cases:
- A connection could not be established
- A connection was lost before the reply was received
- A timeout expired
- An exception occurred while sending the request or receiving the reply
- An error occurred in the server while dispatching the request that causes the server
the official-site-doc says we can set up retry-timeout and client will retry timeout invocation
[ Full content available at: https://github.com/apache/incubator-dubbo/issues/3215 ]
This message was relayed via gitbox.apache.org for notifications@dubbo.apache.org
[GitHub] [incubator-dubbo] Kiddinglife closed issue #3215: How Dubbo
handles the failed RPC Invocation with different failing reasons?
Posted by "Kiddinglife (GitHub)" <gi...@apache.org>.
[ issue closed by Kiddinglife ]
[ Full content available at: https://github.com/apache/incubator-dubbo/issues/3215 ]
This message was relayed via gitbox.apache.org for notifications@dubbo.apache.org
[GitHub] [incubator-dubbo] manzhizhen commented on issue #3215: How
Dubbo handles the failed RPC Invocation with different failing reasons?
Posted by "manzhizhen (GitHub)" <gi...@apache.org>.
Then I have a problem, since the consumer side can send messages of the same batch number in multiple threads, then what is the meaning of guaranteeing the same thread consumption on the provider side? Can you give a scene?
那我有个问题，既然consumer端可以多线程发送同一批次号的消息，那么在provider端保证同一线程消费的意义在哪里？能举个场景吗？
[ Full content available at: https://github.com/apache/incubator-dubbo/issues/3215 ]
This message was relayed via gitbox.apache.org for notifications@dubbo.apache.org
[GitHub] [incubator-dubbo] manzhizhen commented on issue #3215: How
Dubbo handles the failed RPC Invocation with different failing reasons?
Posted by "manzhizhen (GitHub)" <gi...@apache.org>.
As for the "at-most-once" semantics, I don't think Dubbo has done that. If we want to do at-most-once, we need to record which requestId has successfully responded on the provider side. When a duplicate requestId arrives, we throw an exception to the consumer side to say that the processing is successful or return the previous value (if there is a cache). At present, we have seen the implementation of dubbo, which should not be done. Personally, it is more appropriate for providers to do idempotent work by themselves.
关于“at-most-once”语义，我认为dubbo是没有做到这一点的，如果想做到at-most-once，在provider端需要记录哪些requestId已经成功应答，当有重复的requestId到来时，给consumer端抛异常说处理成功或者将之前的值（如果有缓存的话）再返回。目前看了dubbo的实现，应该是没有这样做的，个人感觉还是provider的业务方自己做幂等更合适点。
[ Full content available at: https://github.com/apache/incubator-dubbo/issues/3215 ]
This message was relayed via gitbox.apache.org for notifications@dubbo.apache.org
[GitHub] [incubator-dubbo] manzhizhen commented on issue #3215: How
Dubbo handles the failed RPC Invocation with different failing reasons?
Posted by "manzhizhen (GitHub)" <gi...@apache.org>.
> 对于批量处理的需求，provider端提供批量处理的接口不是更合理吗，比如接口接受list参数，服务提供方按顺序处理请求
@Kiddinglife 的意思应该是顺序调不同的provider的服务
[ Full content available at: https://github.com/apache/incubator-dubbo/issues/3215 ]
This message was relayed via gitbox.apache.org for notifications@dubbo.apache.org
[GitHub] [incubator-dubbo] Kiddinglife commented on issue #3215: How
Dubbo handles the failed RPC Invocation with different failing reasons?
Posted by "Kiddinglife (GitHub)" <gi...@apache.org>.
@manzhizhen so far so good. thanks. I am closing this issue and could re-open in the future if needed. lol.
[ Full content available at: https://github.com/apache/incubator-dubbo/issues/3215 ]
This message was relayed via gitbox.apache.org for notifications@dubbo.apache.org
[GitHub] [incubator-dubbo] Kiddinglife commented on issue #3215: How
Dubbo handles the failed RPC Invocation with different failing reasons?
Posted by "Kiddinglife (GitHub)" <gi...@apache.org>.
Any updates on failed rpc handlings?
[ Full content available at: https://github.com/apache/incubator-dubbo/issues/3215 ]
This message was relayed via gitbox.apache.org for notifications@dubbo.apache.org
[GitHub] [incubator-dubbo] manzhizhen commented on issue #3215: How
Dubbo handles the failed RPC Invocation with different failing reasons?
Posted by "manzhizhen (GitHub)" <gi...@apache.org>.
Seeing your case, you probably understand what effect you want, and it doesn't matter if you specify a thread to execute on the provider side.
To ensure that the messages are executed in order, the RPC method is better. For example, if you perform the next RPC after the previous RPC call, you can guarantee that the first RPC is executed first. The secondary RPC, the consumer terminal machine for loop, is implemented.
But if you really want Dubbo to implement, there are still a few issues to discuss, such as:
1. How do bulk messages respond in batches?
2. What should I do if the bulk message fails to execute halfway?
In fact, the easiest way is to apply the package to the for loop call. Of course, if the framework is implemented, you can reduce some network back and forth overhead.
看到你举的case，大概明白你想要什么效果了，感觉和provider端指定一个线程执行关系到不大。
要保证消息按照顺序执行，通过RPC的方式是比较好做的，比如你在前一次RPC调用结束后再进行下一次RPC，就可以百分百保证是先执行完第一次RPC再执行第二次RPC，即consumer端子机for循环来实现。
但如果真要Dubbo来实现，还有几个问题需要讨论，例如：
1. 批量消息如何批量应答？
2. 批量消息中途执行失败该如何处理？
其实，最简单的方式，就是应用自己对for循环调用进行下包装，当然，如果框架实现，可以减少一些网络来回开销。
[ Full content available at: https://github.com/apache/incubator-dubbo/issues/3215 ]
This message was relayed via gitbox.apache.org for notifications@dubbo.apache.org
[GitHub] [incubator-dubbo] manzhizhen commented on issue #3215: How
Dubbo handles the failed RPC Invocation with different failing reasons?
Posted by "manzhizhen (GitHub)" <gi...@apache.org>.
It can be seen that you really have a strong interest in this aspect, I did not think so carefully when I looked at Dubbo. Let me talk about my understanding first (if the following description is wrong, please point out, thank you), in fact, no matter the business side system, RPC framework, there is no need to divide the network error so fine, but I still look at Dubbo In this aspect of implementation, let's first talk about the application startup, without considering the delay link, when the consumer initializes, it will try to establish a link with each available provider, even if we set check= on the consumer side "false", if there are four cases of a, b, c, and d that you describe at this time, if it is check="true", it will directly cause the application to fail to start. If it is check="false", it will be simple. Print the alarm log, we can find the answer from the constructor of org.apache.dubbo.remoting.transport.AbstractClient:
可以看出你确实对这方面有着浓厚的兴趣，我在看Dubbo时都没想得这么细。先来说说我的理解吧（下面的描述如有错误请直接指出，谢谢），其实不管对于业务方系统、RPC框架，都没必要将网络错误分这么细，但我仍然还是看了下Dubbo在这方面的实现，咱们先说说应用启动的时候，在不考虑延迟链接的情况下，当consumer初始化时，会尝试和每一个可用的provider建立链接，即使我们在consumer端设置的是check="false"，如果在这时候发生你描述的a,b,c,d四种情况，如果是check="true"，那么将直接导致应用启动失败，如果是check="false",那么将简单打印告警日志，这个我们可以从org.apache.dubbo.remoting.transport.AbstractClient的构造函数中找到答案：
`
public AbstractClient(URL url, ChannelHandler handler) throws RemotingException {
... 略 ...
try {
// connect.
connect();
if (logger.isInfoEnabled()) {
logger.info("Start " + getClass().getSimpleName() + " " + NetUtils.getLocalAddress() + " connect to the server " + getRemoteAddress());
}
} catch (RemotingException t) {
// 这里check属性起到了关键作用
if (url.getParameter(Constants.CHECK_KEY, true)) {
close();
throw t;
} else {
logger.warn("Failed to start " + getClass().getSimpleName() + " " + NetUtils.getLocalAddress()
+ " connect to the server " + getRemoteAddress() + " (check == false, ignore and retry later!), cause: " + t.getMessage(), t);
}
} catch (Throwable t) {
close();
throw new RemotingException(url.toInetSocketAddress(), null,
"Failed to start " + getClass().getSimpleName() + " " + NetUtils.getLocalAddress()
+ " connect to the server " + getRemoteAddress() + ", cause: " + t.getMessage(), t);
}
... 略 ...
}
`
After the consumer is initialized successfully and the application is started, if the provider service is found, if the link is not established, the link will be tried first. If the link fails or the data fails, the exception will be thrown. See the AbstractClient code:
consumer初始化成功并且应用启动后，当调provider服务时，如果发现链接未建立，会尝试先建立链接，这时候如果建链失败，或者发送数据失败，都会抛异常出来，见AbstractClient代码：
`
@Override
public void send(Object message, boolean sent) throws RemotingException {
if (send_reconnect && !isConnected()) {
connect();
}
Channel channel = getChannel();
//TODO Can the value returned by getChannel() be null? need improvement.
if (channel == null || !channel.isConnected()) {
throw new RemotingException(this, "message can not send, because channel is closed . url:" + getUrl());
}
channel.send(message, sent);
}
`
That is to say, sending a message at runtime fails, Dubbo will only deal with two major classes and network-related exceptions (that is, regardless of InvocationTargetException), one is a timeout (TimeoutException), and the other is a remote error (RemotingException), but The application throws are RpcException, but the code is different (see the definition of RpcException).
If a call fails, then depending on the cluster strategy used, choose to retry or immediately fail or ignore the return, etc. Interested can see the implementation of subclasses of org.apache.dubbo.rpc.protocol.AbstractInvokerd#invoke and AbstractClusterInvoker.
From what I have learned so far, Dubbo's exception handling mechanism for the network is not as detailed as you listed. I hope my answer will help you. If you make mistakes, please point out, thank you again! !
也就是说，在运行时发送消息失败，Dubbo这边只会处理两大类和网络相关的异常（即不考虑InvocationTargetException），一个是超时（TimeoutException），另一个就是远程报错（RemotingException），但对应用抛的，都是RpcException，只是code不同（见RpcException的定义）。
如果一次调用失败，那么将根据采用的集群策略，选择重试或者立即失败或者忽略返回等，感兴趣可以看下org.apache.dubbo.rpc.protocol.AbstractInvokerd#invoke和AbstractClusterInvoker的子类的实现。
从目前我了解到的情况来看，Dubbo关于网络的异常处理机制并没有你列举的那么细，希望我的回答对你能有所帮助，如果错误请直接指出，再次感谢！！
[ Full content available at: https://github.com/apache/incubator-dubbo/issues/3215 ]
This message was relayed via gitbox.apache.org for notifications@dubbo.apache.org
[GitHub] [incubator-dubbo] manzhizhen commented on issue #3215: How
Dubbo handles the failed RPC Invocation with different failing reasons?
Posted by "manzhizhen (GitHub)" <gi...@apache.org>.
Seeing your case, you probably understand what effect you want, and it doesn't matter if you specify a thread to execute on the provider side.
To ensure that the messages are executed in order, the RPC method is better. For example, if you perform the next RPC after the previous RPC call, you can guarantee that the first RPC is executed first. The secondary RPC, that is, the consumer side itself is implemented by a loop.
But if you really want Dubbo to implement, there are still a few issues to discuss, such as:
1. How do bulk messages respond in batches?
2. What should I do if the bulk message fails to execute halfway?
In fact, the easiest way is to apply the package to the for loop call. Of course, if the framework is implemented, you can reduce some network back and forth overhead.
看到你举的case，大概明白你想要什么效果了，感觉和provider端指定一个线程执行关系到不大。
要保证消息按照顺序执行，通过RPC的方式是比较好做的，比如你在前一次RPC调用结束后再进行下一次RPC，就可以百分百保证是先执行完第一次RPC再执行第二次RPC，即consumer端自己for循环来实现。
但如果真要Dubbo来实现，还有几个问题需要讨论，例如：
1. 批量消息如何批量应答？
2. 批量消息中途执行失败该如何处理？
其实，最简单的方式，就是应用自己对for循环调用进行下包装，当然，如果框架实现，可以减少一些网络来回开销。
[ Full content available at: https://github.com/apache/incubator-dubbo/issues/3215 ]
This message was relayed via gitbox.apache.org for notifications@dubbo.apache.org
[GitHub] [incubator-dubbo] manzhizhen commented on issue #3215: How
Dubbo handles the failed RPC Invocation with different failing reasons?
Posted by "manzhizhen (GitHub)" <gi...@apache.org>.
It can be seen that you really have a strong interest in this aspect, I did not think so carefully when I looked at Dubbo. Let me talk about my understanding first (if the following description is wrong, please point out, thank you), in fact, no matter the business side system, RPC framework, there is no need to divide the network error so fine, but I still look at Dubbo In this aspect of implementation, let's first talk about the application startup, without considering the delay link, when the consumer initializes, it will try to establish a link with each available provider, even if we set check= on the consumer side "false", if there are four cases of a, b, c, and d that you describe at this time, if it is check="true", it will directly cause the application to fail to start. If it is check="false", it will be simple. Print the alarm log, we can find the answer from the constructor of org.apache.dubbo.remoting.transport.AbstractClient:
可以看出你确实对这方面有着浓厚的兴趣，我在看Dubbo时都没想得这么细。先来说说我的理解吧（下面的描述如有错误请直接指出，谢谢），其实不管对于业务方系统、RPC框架，都没必要将网络错误分这么细，但我仍然还是看了下Dubbo在这方面的实现，咱们先说说应用启动的时候，在不考虑延迟链接的情况下，当consumer初始化时，会尝试和每一个可用的provider建立链接，即使我们在consumer端设置的是check="false"，如果在这时候发生你描述的a,b,c,d四种情况，如果是check="true"，那么将直接导致应用启动失败，如果是check="false",那么将简单打印告警日志，这个我们可以从org.apache.dubbo.remoting.transport.AbstractClient的构造函数中找到答案：
`public AbstractClient(URL url, ChannelHandler handler) throws RemotingException {
... 略 ...
try {
// connect.
connect();
if (logger.isInfoEnabled()) {
logger.info("Start " + getClass().getSimpleName() + " " + NetUtils.getLocalAddress() + " connect to the server " + getRemoteAddress());
}
} catch (RemotingException t) {
// 这里check属性起到了关键作用
if (url.getParameter(Constants.CHECK_KEY, true)) {
close();
throw t;
} else {
logger.warn("Failed to start " + getClass().getSimpleName() + " " + NetUtils.getLocalAddress()
+ " connect to the server " + getRemoteAddress() + " (check == false, ignore and retry later!), cause: " + t.getMessage(), t);
}
} catch (Throwable t) {
close();
throw new RemotingException(url.toInetSocketAddress(), null,
"Failed to start " + getClass().getSimpleName() + " " + NetUtils.getLocalAddress()
+ " connect to the server " + getRemoteAddress() + ", cause: " + t.getMessage(), t);
}
... 略 ...
}
`
After the consumer is initialized successfully and the application is started, if the provider service is found, if the link is not established, the link will be tried first. If the link fails or the data fails, the exception will be thrown. See the AbstractClient code:
consumer初始化成功并且应用启动后，当调provider服务时，如果发现链接未建立，会尝试先建立链接，这时候如果建链失败，或者发送数据失败，都会抛异常出来，见AbstractClient代码：
`
@Override
public void send(Object message, boolean sent) throws RemotingException {
if (send_reconnect && !isConnected()) {
connect();
}
Channel channel = getChannel();
//TODO Can the value returned by getChannel() be null? need improvement.
if (channel == null || !channel.isConnected()) {
throw new RemotingException(this, "message can not send, because channel is closed . url:" + getUrl());
}
channel.send(message, sent);
}
`
That is to say, sending a message at runtime fails, Dubbo will only deal with two major classes and network-related exceptions (that is, regardless of InvocationTargetException), one is a timeout (TimeoutException), and the other is a remote error (RemotingException), but The application throws are RpcException, but the code is different (see the definition of RpcException).
If a call fails, then depending on the cluster strategy used, choose to retry or immediately fail or ignore the return, etc. Interested can see the implementation of subclasses of org.apache.dubbo.rpc.protocol.AbstractInvokerd#invoke and AbstractClusterInvoker.
From what I have learned so far, Dubbo's exception handling mechanism for the network is not as detailed as you listed. I hope my answer will help you. If you make mistakes, please point out, thank you again! !
也就是说，在运行时发送消息失败，Dubbo这边只会处理两大类和网络相关的异常（即不考虑InvocationTargetException），一个是超时（TimeoutException），另一个就是远程报错（RemotingException），但对应用抛的，都是RpcException，只是code不同（见RpcException的定义）。
如果一次调用失败，那么将根据采用的集群策略，选择重试或者立即失败或者忽略返回等，感兴趣可以看下org.apache.dubbo.rpc.protocol.AbstractInvokerd#invoke和AbstractClusterInvoker的子类的实现。
从目前我了解到的情况来看，Dubbo关于网络的异常处理机制并没有你列举的那么细，希望我的回答对你能有所帮助，如果错误请直接指出，再次感谢！！
[ Full content available at: https://github.com/apache/incubator-dubbo/issues/3215 ]
This message was relayed via gitbox.apache.org for notifications@dubbo.apache.org
[GitHub] [incubator-dubbo] Kiddinglife commented on issue #3215: How
Dubbo handles the failed RPC Invocation with different failing reasons?
Posted by "Kiddinglife (GitHub)" <gi...@apache.org>.
> @Kiddinglife 的意思应该是顺序调不同的provider的服务
@Kiddinglife is saying the server should execute the multi-invocations in the same ordering as the client defines them.
@manzhizhen Something I need to point out is that the sample functions f1 anf f2 in the above are expected to be defined and executed in the scope of a single server's process instead of multi-server.
regards.
[ Full content available at: https://github.com/apache/incubator-dubbo/issues/3215 ]
This message was relayed via gitbox.apache.org for notifications@dubbo.apache.org
[GitHub] [incubator-dubbo] manzhizhen commented on issue #3215: How
Dubbo handles the failed RPC Invocation with different failing reasons?
Posted by "manzhizhen (GitHub)" <gi...@apache.org>.
It can be seen that you really have a strong interest in this aspect, I did not think so carefully when I looked at Dubbo. Let me talk about my understanding first (if the following description is wrong, please point out, thank you), in fact, no matter the business side system, RPC framework, there is no need to divide the network error so fine, but I still look at Dubbo In this aspect of implementation, let's first talk about the application startup, without considering the delay link, when the consumer initializes, it will try to establish a link with each available provider, even if we set check= on the consumer side "false", if there are four cases of a, b, c, and d that you describe at this time, if it is check="true", it will directly cause the application to fail to start. If it is check="false", it will be simple. Print the alarm log, we can find the answer from the constructor of org.apache.dubbo.remoting.transport.AbstractClient:
可以看出你确实对这方面有着浓厚的兴趣，我在看Dubbo时都没想得这么细。先来说说我的理解吧（下面的描述如有错误请直接指出，谢谢），其实不管对于业务方系统、RPC框架，都没必要将网络错误分这么细，但我仍然还是看了下Dubbo在这方面的实现，咱们先说说应用启动的时候，在不考虑延迟链接的情况下，当consumer初始化时，会尝试和每一个可用的provider建立链接，即使我们在consumer端设置的是check="false"，如果在这时候发生你描述的a,b,c,d四种情况，如果是check="true"，那么将直接导致应用启动失败，如果是check="false",那么将简单打印告警日志，这个我们可以从org.apache.dubbo.remoting.transport.AbstractClient的构造函数中找到答案：
`
public AbstractClient(URL url, ChannelHandler handler) throws RemotingException {
... 略 ...
try {
// connect.
connect();
if (logger.isInfoEnabled()) {
logger.info("Start " + getClass().getSimpleName() + " " + NetUtils.getLocalAddress() + " connect to the server " + getRemoteAddress());
}
} catch (RemotingException t) {
// 这里check属性起到了关键作用
if (url.getParameter(Constants.CHECK_KEY, true)) {
close();
throw t;
} else {
logger.warn("Failed to start " + getClass().getSimpleName() + " " + NetUtils.getLocalAddress()
+ " connect to the server " + getRemoteAddress() + " (check == false, ignore and retry later!), cause: " + t.getMessage(), t);
}
} catch (Throwable t) {
close();
throw new RemotingException(url.toInetSocketAddress(), null,
"Failed to start " + getClass().getSimpleName() + " " + NetUtils.getLocalAddress()
+ " connect to the server " + getRemoteAddress() + ", cause: " + t.getMessage(), t);
}
... 略 ...
}
`
After the consumer is initialized successfully and the application is started, if the provider service is found, if the link is not established, the link will be tried first. If the link fails or the data fails, the exception will be thrown. See the AbstractClient code:
consumer初始化成功并且应用启动后，当调provider服务时，如果发现链接未建立，会尝试先建立链接，这时候如果建链失败，或者发送数据失败，都会抛异常出来，见AbstractClient代码：
`
@Override
public void send(Object message, boolean sent) throws RemotingException {
if (send_reconnect && !isConnected()) {
connect();
}
Channel channel = getChannel();
//TODO Can the value returned by getChannel() be null? need improvement.
if (channel == null || !channel.isConnected()) {
throw new RemotingException(this, "message can not send, because channel is closed . url:" + getUrl());
}
channel.send(message, sent);
}
`
That is to say, sending a message at runtime fails, Dubbo will only deal with two major classes and network-related exceptions (that is, regardless of InvocationTargetException), one is a timeout (TimeoutException), and the other is a remote error (RemotingException), but The application throws are RpcException, but the code is different (see the definition of RpcException).
If a call fails, then depending on the cluster strategy used, choose to retry or immediately fail or ignore the return, etc. Interested can see the implementation of subclasses of org.apache.dubbo.rpc.protocol.AbstractInvokerd#invoke and AbstractClusterInvoker.
From what I have learned so far, Dubbo's exception handling mechanism for the network is not as detailed as you listed. I hope my answer will help you. If you make mistakes, please point out, thank you again! !
也就是说，在运行时发送消息失败，Dubbo这边只会处理两大类和网络相关的异常（即不考虑InvocationTargetException），一个是超时（TimeoutException），另一个就是远程报错（RemotingException），但对应用抛的，都是RpcException，只是code不同（见RpcException的定义）。
如果一次调用失败，那么将根据采用的集群策略，选择重试或者立即失败或者忽略返回等，感兴趣可以看下org.apache.dubbo.rpc.protocol.AbstractInvokerd#invoke和AbstractClusterInvoker的子类的实现。
从目前我了解到的情况来看，Dubbo关于网络的异常处理机制并没有你列举的那么细，希望我的回答对你能有所帮助，如果错误请直接指出，再次感谢！！
[ Full content available at: https://github.com/apache/incubator-dubbo/issues/3215 ]
This message was relayed via gitbox.apache.org for notifications@dubbo.apache.org
[GitHub] [incubator-dubbo] manzhizhen commented on issue #3215: How
Dubbo handles the failed RPC Invocation with different failing reasons?
Posted by "manzhizhen (GitHub)" <gi...@apache.org>.
about any updates on failed rpc handlings, I'll get back to you tomorrow.
[ Full content available at: https://github.com/apache/incubator-dubbo/issues/3215 ]
This message was relayed via gitbox.apache.org for notifications@dubbo.apache.org
[GitHub] [incubator-dubbo] Kiddinglife commented on issue #3215: How
Dubbo handles the failed RPC Invocation with different failing reasons?
Posted by "Kiddinglife (GitHub)" <gi...@apache.org>.
Hi @manzhizhen,
I updated my question. plz take a look and let me know how you think about it.
regards.
[ Full content available at: https://github.com/apache/incubator-dubbo/issues/3215 ]
This message was relayed via gitbox.apache.org for notifications@dubbo.apache.org
[GitHub] [incubator-dubbo] kexianjun commented on issue #3215: How
Dubbo handles the failed RPC Invocation with different failing reasons?
Posted by "kexianjun (GitHub)" <gi...@apache.org>.
对于批量处理的需求，provider端提供批量处理的接口不是更合理吗，比如接口接受list参数，服务提供方按顺序处理请求
[ Full content available at: https://github.com/apache/incubator-dubbo/issues/3215 ]
This message was relayed via gitbox.apache.org for notifications@dubbo.apache.org
[GitHub] [incubator-dubbo] Kiddinglife commented on issue #3215: How
Dubbo handles the failed RPC Invocation with different failing reasons?
Posted by "Kiddinglife (GitHub)" <gi...@apache.org>.
yes, so it is.
On Sun, 13 Jan 2019 at 11:36 am, yizhenqiang <no...@github.com> wrote:
Regarding the first question, you refer to the batch message, which is only consumed and answered by one thread on the provider side. Then the batch message can be sent by different threads on the consumer side, as long as the batch number is one, right?
?????????????????provider???????????????????????consumer???????????????????????????
?
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub<https://github.com/apache/incubator-dubbo/issues/3215#issuecomment-453792179>, or mute the thread<https://github.com/notifications/unsubscribe-auth/AKFrGbZ_N9JQlSoZWr71Clkh2luwdYDDks5vCn-ngaJpZM4Z85nt>.
[ Full content available at: https://github.com/apache/incubator-dubbo/issues/3215 ]
This message was relayed via gitbox.apache.org for notifications@dubbo.apache.org
[GitHub] [incubator-dubbo] Kiddinglife commented on issue #3215: How
Dubbo handles the failed RPC Invocation with different failing reasons?
Posted by "Kiddinglife (GitHub)" <gi...@apache.org>.
> @Kiddinglife 的意思应该是顺序调不同的provider的服务
@Kiddinglife is saying the server should execute the multi-invocations in the same ordering as the client defines them.
@manzhizhen you are right. Something I need to point out is that the sample functions f1 anf f2 in the above are expected to be defined and executed in the scope of a single server's process instead of multi-server.
regards.
[ Full content available at: https://github.com/apache/incubator-dubbo/issues/3215 ]
This message was relayed via gitbox.apache.org for notifications@dubbo.apache.org
[GitHub] [incubator-dubbo] Kiddinglife commented on issue #3215: How
Dubbo handles the failed RPC Invocation with different failing reasons?
Posted by "Kiddinglife (GitHub)" <gi...@apache.org>.
> @Kiddinglife 的意思应该是顺序调不同的provider的服务
@Kiddinglife is saying the server should execute the multi-invocations in the same ordering as the client defines them.
@manzhizhen Something I need to point out is that the sample functions f1 anf f2 in the above are expected to be defined and executed in the scope of a single server's process instead of multi-servers.
regards.
[ Full content available at: https://github.com/apache/incubator-dubbo/issues/3215 ]
This message was relayed via gitbox.apache.org for notifications@dubbo.apache.org
[GitHub] [incubator-dubbo] manzhizhen commented on issue #3215: How
Dubbo handles the failed RPC Invocation with different failing reasons?
Posted by "manzhizhen (GitHub)" <gi...@apache.org>.
Regarding the first question, you refer to the batch message, which is only consumed and answered by one thread on the provider side. Then the batch message can be sent by different threads on the consumer side, as long as the batch number is one, right?
关于第一个问题，你指的批量消息，在provider端只由一个线程来消费和应答，那么这个批量消息在consumer端可以由不同的线程来发送，只要批次号是一个就行了是吧？
[ Full content available at: https://github.com/apache/incubator-dubbo/issues/3215 ]
This message was relayed via gitbox.apache.org for notifications@dubbo.apache.org
[GitHub] [incubator-dubbo] manzhizhen commented on issue #3215: How
Dubbo handles the failed RPC Invocation with different failing reasons?
Posted by "manzhizhen (GitHub)" <gi...@apache.org>.
> > @Kiddinglife 的意思应该是顺序调不同的provider的服务
> > @Kiddinglife is saying the server should execute the multi-invocations in the same ordering as the client defines them.
>
> @manzhizhen Something I need to point out is that the sample functions f1 anf f2 in the above are expected to be defined and executed in the scope of a single server's process instead of multi-servers.
>
> regards.
Sorry, I still don't understand what kind of problem you can solve in this way. The business party can also achieve this effect by installing the order itself, and can get the return value every time.
抱歉，我还是没有理解到你说的这种方式能解决哪些问题，业务方自己安装顺序调用其实也能达到此效果，并且每次调用都能拿到返回值。
[ Full content available at: https://github.com/apache/incubator-dubbo/issues/3215 ]
This message was relayed via gitbox.apache.org for notifications@dubbo.apache.org
[GitHub] [incubator-dubbo] Kiddinglife commented on issue #3215: How
Dubbo handles the failed RPC Invocation with different failing reasons?
Posted by "Kiddinglife (GitHub)" <gi...@apache.org>.
It really depends on the imp. One simple way is to bundle all the batched invocations in the same invocation message, in which case it can be sent by any available thread in a client.
We can also put two invocations across more than one invocation message in client but it requires further ordering of the received invocation messages in server.
The key point is the requirement of the ordering of the invocations that are involed in a batch.
Pseudo codes may look like this:
Client side
Batchcall bc = new Batchcall:
batchcall.add(f1);
Batchcall.add(f2);
Batchcall.send()
In Server side. The ordering of invocation must be f1 then f2 regardless of whichever thread is executing the invocation.
Regards,
Thanks.
On Sun, 13 Jan 2019 at 12:07 pm, yizhenqiang <no...@github.com>> wrote:
Then I have a problem, since the consumer side can send messages of the same batch number in multiple threads, then what is the meaning of guaranteeing the same thread consumption on the provider side? Can you give a scene?
那我有个问题，既然consumer端可以多线程发送同一批次号的消息，那么在provider端保证同一线程消费的意义在哪里？能举个场景吗？
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub<https://github.com/apache/incubator-dubbo/issues/3215#issuecomment-453793466>, or mute the thread<https://github.com/notifications/unsubscribe-auth/AKFrGeJ5zlm-2iVG5QRf4xxMXVXlT9nBks5vCobGgaJpZM4Z85nt>.
[ Full content available at: https://github.com/apache/incubator-dubbo/issues/3215 ]
This message was relayed via gitbox.apache.org for notifications@dubbo.apache.org
[GitHub] [incubator-dubbo] Kiddinglife commented on issue #3215: How
Dubbo handles the failed RPC Invocation with different failing reasons?
Posted by "Kiddinglife (GitHub)" <gi...@apache.org>.
all right. Thanks for your time in the discussion about batched invocation. I think we can let it go at this moment.
It is more interesting if someone can tell me what actions the Dubbo take in such cases I mentioned above?
Regards.
On Mon, 14 Jan 2019 at 1:51 am, yizhenqiang <no...@github.com>> wrote:
@Kiddinglife<https://github.com/Kiddinglife> 的意思应该是顺序调不同的provider的服务
@Kiddinglife<https://github.com/Kiddinglife> is saying the server should execute the multi-invocations in the same ordering as the client defines them.
@manzhizhen<https://github.com/manzhizhen> Something I need to point out is that the sample functions f1 anf f2 in the above are expected to be defined and executed in the scope of a single server's process instead of multi-servers.
regards.
Sorry, I still don't understand what kind of problem you can solve in this way. The business party can also achieve this effect by installing the order itself, and can get the return value every time.
抱歉，我还是没有理解到你说的这种方式能解决哪些问题，业务方自己安装顺序调用其实也能达到此效果，并且每次调用都能拿到返回值。
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub<https://github.com/apache/incubator-dubbo/issues/3215#issuecomment-453835890>, or mute the thread<https://github.com/notifications/unsubscribe-auth/AKFrGTptONVO0HYbnp9dWf7U-yfNlS8wks5vC0fugaJpZM4Z85nt>.
[ Full content available at: https://github.com/apache/incubator-dubbo/issues/3215 ]
This message was relayed via gitbox.apache.org for notifications@dubbo.apache.org