foreword
SOFA-RPC supports data link transparent transmission function, the official explanation:
The link data transparent transmission function allows applications to store data in the calling context, so that applications on the entire link can operate the data. The usage method is as follows. Data can be put into the request and response of the link for transparent transmission, and the corresponding data in the link can be obtained.
How to use:
RpcInvokeContext.getContext().putRequestBaggage("key_request","value_request");
RpcInvokeContext.getContext().putResponseBaggage("key_response","value_response");
RpcInvokeContext.getContext().getAllRequestBaggage("key_request");
RpcInvokeContext.getContext().getAllRequestBaggage("key_response");Source code analysis
Start with this 4-sentence code.
Key class: RpcInvokeContext, this class is a 基于ThreadLocal的面向业务开发者使用的上下文传递对象.
A ThreadLocal object is maintained internally.
protected static final ThreadLocal<RpcInvokeContext> LOCAL = new ThreadLocal<RpcInvokeContext>();value is an RpcInvokeContext object.
When calling getContext, the RpcInvokeContext object is obtained from the current thread.
The class defines the following properties:
- boolean BAGGAGE_ENABLE Whether to enable the context transparent transmission function, after closing, it will improve performance
- Integer timeout User-defined timeout, valid for a single call
- String targetURL User-defined address of the other party, which takes effect after a single call
- String targetGroup User-defined target group
- SofaResponseCallback responseCallback User-defined Callback, effective for a single call
- ResponseFuture<?> future
- ConcurrentMap
- Map
- Map
Knowing the basic data structure, look at the above methods:
- putRequestBaggage（）
- putResponseBaggage（）
- getAllRequestBaggage（）
- getAllRequestBaggage（）
In fact, the data is obtained from the Map. However, it seems that the official example is a bit problematic, and the latter two examples are wrong. There is no key. Wait for me to file an issue.
Summarize
This function reminds me of the CurrentUser function I used in the company project, and also used ThreadLocal to store the user's information in the thread, so that the commonly used data does not have to be passed in the method parameters, which saves a lot of trouble. It's just that when it's asynchronous, there may be some problems, and you need to manually pass ThreadLocal to the asynchronous thread.
However, I did not use manual transfer. I designed it like this: Customize the thread pool and thread factory. When the thread factory creates a thread, it will copy the ThreadLocal of the main thread to the asynchronous thread, and customize the thread class. Delete ThreadLocal in the block, a very perfect design. This way you don't have to pass it manually every time and delete it manually.
Well, this function is still very simple. But it is very practical, but it would be nice if I could add the function I designed above! Ha ha!