You are viewing a plain text version of this content. The canonical link for it is here.
Posted to notifications@dubbo.apache.org by "carryxyh (GitHub)" <gi...@apache.org> on 2019/01/23 12:24:53 UTC
[GitHub] [incubator-dubbo] carryxyh commented on pull request #3017:
Refresh invocation's attachments in each invoke.
> What if user has overridden the timeout or token value in RpcContext/Invocation, if you put replace addAttachmentsIfAbsent with addAttachments and put it at the last place, the user will never has a chance to override the keys listed here
I have previously considered using RpcContext to modify the timeout (group) scenario. I personally are not sure if there is a intention to leave a back door or a design flaw. But I rarely encounter the need to use RpcContext to modify the timeout, so the overlay is used directly.
I have previously considered using RpcContext to modify the timeout (token) scenario. I personally are not sure if there is a intention to leave a back door or a design flaw. But I rarely encounter the need to use RpcContext to modify the timeout, so the overlay is used directly.
> Cannot we just remove or replace the INTERFACE_KEY with the right one?
Yes, we can.
But it seems that `timeout` and `group` may have the same problem as interface. For example, in the link of `A -> B -> C`, `B` receives the `timeout` from `A`. At this time, in the link where `B` calls `C`, it is possible to use the timeout of `A -> B` instead of the timeout of `B -> C`. Should we try to avoid this risk?
> I even find that the INTERFACE_KEY useless on the wire.
I see that there are still many places that quote INTERFACE_KEY. Is it my understanding of what you mean wrong?
[ Full content available at: https://github.com/apache/incubator-dubbo/pull/3017 ]
This message was relayed via gitbox.apache.org for notifications@dubbo.apache.org