Hi Dan, I have submitted a patch via https://issues.apache.org/jira/browse/CXF-1410
RequestContexts are thread local but the proxy also maintains a map. On a call to getRequestContext() the thread local is initialized from the proxy map. Any mods made to the thread local are echoed to the proxy map but on an invocation, the thread local contexts are used. In this way, threads have safe access to their context between calls to getRequestContexts(). There is some more detail in the jira. Gary. > -----Original Message----- > From: Daniel Kulp [mailto:[EMAIL PROTECTED] > Sent: 23 January 2008 20:29 > To: [email protected] > Cc: Tully, Gary > Subject: Re: JAXWS proxy thread safety 'with' requestContext > > > 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/[EMAIL PROTECTED]/msg00150.htm > >l [3] > > > http://www.mail-archive.com/[email protected]/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 > [EMAIL PROTECTED] > http://www.dankulp.com/blog > ---------------------------- IONA Technologies PLC (registered in Ireland) Registered Number: 171387 Registered Address: The IONA Building, Shelbourne Road, Dublin 4, Ireland
