Mailing-List: contact cxf-issues-help@incubator.apache.org; run by ezmlm
Precedence: bulk
Reply-To: cxf-dev@incubator.apache.org
Message-ID: <22301080.1201819148664.JavaMail.jira@brutus>
Date: Thu, 31 Jan 2008 14:39:08 -0800 (PST)
From: "Daniel Kulp (JIRA)" <jira@apache.org>
To: cxf-issues@incubator.apache.org
Subject: [jira] Commented: (CXF-1410) Allow thread safe access to proxy with
 requestContext usage..
In-Reply-To: <10088246.1201704518783.JavaMail.jira@brutus>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit


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

Daniel Kulp commented on CXF-1410:
----------------------------------


Gary,   

There is a problem with your patch in that it doesn't work for the normal case of:

Thread1- deployer thread or something configures the URL on the context

Thread2 then makes an invokation without calling getRequestContext() at all.  In your case, no context values are copied at all as the call to getThreadRequestContext()  creates a new, unitialized hashmap.


Second issue:
If thread 1 in a thread pool configures some stuff in the request context and makes a request
Then thread 2 in a thread pool re-configures some stuff.
Then another request is made on thread 1 again, it won't see anything reconfigured by thread 2.  


What I think needs to happen is that the ThreadLocal requetcontext needs to be set back to null after the invoke.   That might make using the contexts a bit more expensive though.   I'll play around a little bit more tomorrow.


> Allow thread safe access to proxy with requestContext usage..
> -------------------------------------------------------------
>
>                 Key: CXF-1410
>                 URL: https://issues.apache.org/jira/browse/CXF-1410
>             Project: CXF
>          Issue Type: Improvement
>          Components: JAX-WS Runtime
>    Affects Versions: 2.0.4
>            Reporter: Gary Tully
>            Priority: Minor
>         Attachments: mt_context.patch
>
>
> It should be possible to cache a proxy and provide thread safe access to it. For example, the following code should work from multiple threads with deterministic results:
>         Greeter greeter = // get cached proxy
>         InvocationHandler handler = Proxy.getInvocationHandler(greeter);
>         Map<String, Object> requestContext = ((BindingProvider)handler).getRequestContext();
>         String threadSpecificaddress = // ... 
>         requestContext.put(BindingProvider.ENDPOINT_ADDRESS_PROPERTY, threadSpecificaddress);
> the proposal is to implement thread local request contexts and manage the mapping from shared proxy request contexts to the thread local.The synchronization point is on a call to getRequestContext. the return is a snapshot of the current shared proxy request context map.
> The map is such that it will echo modifications into the shared map. But further modifications to teh shared map will not be visible to the calling thread until  subsequent getRequestContext call is made.
> In other words, an invoke works with a copy of the thread local context which takes into account modifications to the shared context at the time of the getRequestContextCall()

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.