Hi all, I'm using CXF 3.0.7 in a Java EE environment and I'm taking advantage from the thread safety of the CXF client proxies (I'm aware that there are limitations). As documented in this<https://cxf.apache.org/faq.html#FAQ-AreJAX-WSclientproxiesthreadsafe?> page the request context can be made thread local (cit. "Thus, anything set there will affect requests on other threads."), but I observed that even after having set the property "thread.local.request.context" it arrives sometimes that some modifications to the request context leak the thread scope, leading potentially to unpredictable behaviors.
Digging in the code I found that the reason is the following. The class org.apache.cxf.endpoint.ClientImpl stores the request context entries in a map called "currentRequestContext". After property "thread.local.request.context" is set to true a call to getRequestContext() triggers the creation of another map of type org.apache.cxf.endpoint.ClientImpl.EchoContext which is associated to the current thread (the mapping is kept in the requestContext map). This should guarantee the per thread isolation. The EchoContext is initialized with the entries of the shared map, and as its name suggests modifications are echoed back to the shared map. The problem is that when accessing the request context for the first time in a thread all the modifications done on other threads do affect the current thread even after "thread.local.request.context" is set to true, due to the initialization of the thread local map with shared one. Could you explain me why modifications to the thread local request context are echoed to the shared map? Can I report this thread scope leak as a bug? As a quick and dirty workaround after setting the "thread.local.request.context" I replace the shared map with a copy that discards all modification in order to counteract the effect of the EchoContext and achive a perfect isolation. Do you see any side-effect or do you have any better solution to propose me? Thanks. Iacopo
