cxf-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "RANADEEP SHARMA (JIRA)" <j...@apache.org>
Subject [jira] [Comment Edited] (CXF-6782) Modifications to JAX-WS client request context leak the thread scope
Date Tue, 01 Nov 2016 19:40:58 GMT

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

RANADEEP SHARMA edited comment on CXF-6782 at 11/1/16 7:40 PM:
---------------------------------------------------------------

Same issue is reproducible with CXF version 3.1.6 too.
The said method in ClientImpl.java code for CXF version 3.1.8 has NOT change either. Do we
have any ETA when this would be fixed and in which version?

Most important - Could someone suggest a workaround to ensure the thread local feature works
as expected? Say, a way to override ClientImpl.java with following method customization, where
a new ConcurrentHashMap is instantiated.

    public Map<String, Object> getRequestContext() {
        if (isThreadLocalRequestContext()) {
            if (!requestContext.containsKey(Thread.currentThread())) {
                Map<String, Object> freshRequestContext = new ConcurrentHashMap<String,
Object>(8, 0.75f, 4);
                requestContext.put(Thread.currentThread(), new EchoContext(freshRequestContext));
            }
            return requestContext.get(Thread.currentThread());
        }
        return currentRequestContext;
    }


was (Author: ranadeep.sharma@gmail.com):
Same issue is reproducible with CXF version 3.1.6 too.
The said method in ClientImpl.java code for CXF version 3.1.8 has change either. Do we have
any ETA when this would be fixed and in which version?

Most important - Could someone suggest a workaround to ensure the thread local feature works
as expected? Say, a way to override ClientImpl.java with following method customization, where
a new ConcurrentHashMap is instantiated.

    public Map<String, Object> getRequestContext() {
        if (isThreadLocalRequestContext()) {
            if (!requestContext.containsKey(Thread.currentThread())) {
                Map<String, Object> freshRequestContext = new ConcurrentHashMap<String,
Object>(8, 0.75f, 4);
                requestContext.put(Thread.currentThread(), new EchoContext(freshRequestContext));
            }
            return requestContext.get(Thread.currentThread());
        }
        return currentRequestContext;
    }

> 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)

Mime
View raw message