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 
[email protected]
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]

Reply via email to