cxf-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Tully, Gary" <Gary.Tu...@iona.com>
Subject JAXWS proxy thread safety 'with' requestContext
Date Wed, 23 Jan 2008 17:25:53 GMT

Hi all,

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.html
[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:vpwun7xxi
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

Mime
View raw message