cxf-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Daniel Kulp <dk...@apache.org>
Subject Re: JAXWS proxy thread safety 'with' requestContext
Date Wed, 23 Jan 2008 20:29:00 GMT

Gary,

I guess I would need more details about your proposed solution.  ( a 
patch would be nice)

I guess what you are describing is basically something like a two stage 
Map of somesort where the "parent" map is in the proxy and the child is 
in the thread local.   All writes would go to both.   All "gets" would 
go child first, then parent if not found.   Likewise iterators would do 
child first, the parent for values not in the child.   Is that about 
correct?

That probably would work fine.  I'd definitely ask Jarek to run the full 
Geronimo suite with it before finallizing it though. 

There would definitely still be some funkyness to it though.  If one 
thread DOESN'T set the ENDPOINT_ADDRESS and another does, the first 
thread would get it.   Likewise for other things in the context like 
Headers and and such.

I honestly think it might be best to just go with a proprietary 
getThreadLocalRequestContext()  or something.      Definitely would make 
it such that the standard JAX-WS API's would remain portable to other 
implementations.

Dan



On Wednesday 23 January 2008, Tully, Gary wrote:
> The current state is that a proxy is thread safe provided you don't
> use context parameters. If you do, all thread safety bets are off.
>
> I would like to see a scenario where a CXF jaxws proxy can be thread
> safe. Either through a config option which makes contexts threadLocal
> or through an non-standard api like
> proxy.getThreadLocalRequestContext() or through some other code
> change, there is a proposal at the end.
>
> I want to determine if this is feasible or if there are some other
> blockers.
>
> There has been a bunch of discussion[2][3][4][5] about this in the
> past and CXF has evolved from a case where request/Reply Contexts were
> threadLocal[1][2] to the current state where replyContexts are thread
> local and requestContexts are per proxy and are copied before an
> invocation. The endpoint address is also reset after an invocation, in
> the event that one of the handlers changes it [3].
>
> The end result is that the CXF Clientimpl and JAXWS proxy that sits
> over it are not thread safe.
>
> It is currently not possible to have two threads predictably use the
> same proxy and do:
>
>  Greeter g = getCachedGreeterProxy(...)
>  URL url = chooseUrl(...);
>  (javax.xml.ws.BindingProvider g).
>     getRequestContext().
>       put(javax.xml.ws.BindingProvider.ENDPOINT_ADDRESS_PROPERTY,
> url); g.greetMe("foo");
>
> Granted, the spec is a little vague[6][3] but I think the above is
> valuable as proxy creation is fairly heavy weight.
>
> There are two use cases that seem to be instrumental in the current
> implementation:
>
> 1) Having a requestContext property persist past a single invocation.
>
> 2) Having one thread create and use a proxy, setting requestContext
> values etc and having another thread use the same proxy as is, but see
> the requestContext properties set by the creator.
>
> I am thinking that a hybrid approach, where the contexts are
> threadLocal, take precedence for the current request and are persisted
> to the proxy, is the best approach.
>
> 1) will work, 2) will work and 3) multiple threads that 'always' set
> their own request context properties will work.
>
>
> Are there more use cases and have I captured the current state of
> play? Is the concept of a thread safe proxy achievable at all? Is
> there other per request state managed by the proxy, attachments etc.
> [6]?
>
> Please advise?
>
> Thanks,
> Gary.
>
> Some of the previous threads:
>
> [1] https://issues.apache.org/jira/browse/CXF-470
> [2]
> http://www.mail-archive.com/cxf-user@incubator.apache.org/msg00150.htm
>l [3]
> http://www.mail-archive.com/cxf-dev@incubator.apache.org/msg02914.html
> [4] https://issues.apache.org/jira/browse/CXF-414
> [5]
> http://markmail.org/message/q2tx7ofm3lpqzjd6#query:+page:1+mid:vpwun7x
>xi 4r67ocv+state:results
> [6]
> http://lists.jboss.org/pipermail/jbossws-dev/2007-December/001096.html
>
> ----------------------------
> IONA Technologies PLC (registered in Ireland)
> Registered Number: 171387
> Registered Address: The IONA Building, Shelbourne Road, Dublin 4,
> Ireland



-- 
J. Daniel Kulp
Principal Engineer, IONA
dkulp@apache.org
http://www.dankulp.com/blog

Mime
View raw message