Hi,ian
Several reasons:
1. It seems that the attachment is based on the convention. We need to put
the information other than the rpc parameter into the attachment. We need
to ensure that the information and the temporary information (start in the
timeoutFilter) do not overlap.
2. The attachment field may be null. This allows us to make some additional
judgments and processing before we can use the attachment field:
if (invocation.getAttachments() != null) {
long start = System.currentTimeMillis();
invocation.getAttachments().put(TIMEOUT_FILTER_START_TIME,
String.valueOf(start));
} else {
if (invocation instanceof RpcInvocation) {
RpcInvocation invc = (RpcInvocation) invocation;
long start = System.currentTimeMillis();
invc.setAttachment(TIMEOUT_FILTER_START_TIME,
String.valueOf(start));
}
}
I am still thinking about this issue recently. It seems that the extra
tempAttachment needs to increase the cost of the transmission.
So I have some hesitation about using tempAttachment. How do you think
about this problem?
Ian Luo <ian....@gmail.com> 于2019年2月18日周一 下午6:26写道：
> Yuhang,
>
> Why it's a bad idea to use invocation#attachments to store the temp data?
>
> Thanks,
> -Ian.
>
>
> On Fri, Feb 15, 2019 at 2:55 PM yuhang xiu <carry...@gmail.com> wrote:
>
> > Hi, everyone
> >
> > Recently, I found that dubbo does not handle the data generated during
> the
> > call process when it is asynchronous.
> >
> > For example, in TimeoutFilter, we used invocation#attachments to hold the
> > data that needs to be passed (start time in TimeoutFilter). But I don't
> > think this way is good, although using Invocation.attachments to pass
> data
> > does not pollute RpcContext.
> >
> > Perhaps a better way is to add a temporary attachment to the Invocation
> > that only maintains the temporary data generated during the call.
> >
> > In addition, I found that we still have a few Filters that are currently
> > problematic in asynchronous scenarios, such as:
> >
> > * ActiveLimitFilter
> > * TraceFilter
> >
> > We should determine a plan as soon as possible and then proceed to fix
> > these Filters.
> >
>
