[jira] [Commented] (CXF-6782) Modifications to JAX-WS client request context leak the thread scope

["Jelle Raaijmakers (JIRA)" <ji...@apache.org>]

    [ https://issues.apache.org/jira/browse/CXF-6782?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15221583#comment-15221583 ] 

Jelle Raaijmakers commented on CXF-6782:
----------------------------------------

We have been using CXF version 2.7.18.redhat-1 as packaged in Red Hat JBoss EAP 6.4.6 which also exposes this problem in highly concurrent situations. Enabling {{thread.local.request.context}} does help to keep the request context separate per thread, but only for one level deep.

For example, the {{Message.PROTOCOL_HEADERS}} property is set on the request context with a value that is an instance of TreeMap<String, List<String>>. Although the request context itself is separate, this map is modified directly if the key already exists.

We are seeing this problem when sending SOAP 1.1 requests using the CXF proxy client:
# Two requests are sent at approximately the same time
# Request 1 sets the SOAPAction header by modifying the PROTOCOL_HEADERS TreeMap (which at that point already exists)
# Request 2 sets the SOAPAction header by modifying the PROTOCOL_HEADERS TreeMap
# Request 1 performs the HTTP request, sending the wrong SOAPAction header
# Request 2 is performed successfully


> Modifications to JAX-WS client request context leak the thread scope
> --------------------------------------------------------------------
>
>                 Key: CXF-6782
>                 URL: https://issues.apache.org/jira/browse/CXF-6782
>             Project: CXF
>          Issue Type: Bug
>          Components: Core
>    Affects Versions: 3.0.7
>         Environment: java version "1.7.0_80"
>            Reporter: Iacopo Rozzo
>         Attachments: CXF-6782_reproducer.tar.gz
>
>
> As documented in [this|https://cxf.apache.org/faq.html#FAQ-AreJAX-WSclientproxiesthreadsafe?] page the request context can be made thread local (??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.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)