[
https://issues.apache.org/jira/browse/CXF-1410?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12565438#action_12565438
]
Gary Tully commented on CXF-1410:
---------------------------------
I am loath to add a new api really on the basis that I think a proxy should be
thread safe and that the spec is broken!
>From what I can gleam, issue #2 is only workable when access to the proxy is
>serialized. Other wise all bets are off.
For example giving a client to a thread pool will lead to arbitrary results, if
they use request contexts. In the appserver case, where there is no control
over what thread, there is no control of when a thread runs either.
I am thinking of a configuration property, thread_safe_proxy (or something
similar) that is false by default. When false, the thread unsafe shared proxy
contexts are used for an invocation(, getRequestContextCopy() can implement it)
thus the last operation on the contexts takes effect. Essentially the request
contexts are shared and a proxy/client needs to be serialised.
if true, the thread local contexts are used for an invocation with the sync
point being a call to getRequestContexts(). The thread local is initialised
from the shared proxy contexts (issue #1)
A user that wants non-spec compliant thread safe access to request contexts can
set this flag and all will work without any application level code change.
The choice of config over api comes down to what would a user expect. Do we
think a proxy should be thread safe? (leaving the spec out of it for a moment!)
But, yes, I agree, without config that changes behaviour, it is nigh impossible
to have getRequestContext() be both spec-test compliant (the spec its self is
vague at best) and thread safe.
> 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.
