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