You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cxf.apache.org by "Tully, Gary" <Ga...@iona.com> on 2008/01/23 18:25:53 UTC
JAXWS proxy thread safety 'with' requestContext
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
Re: JAXWS proxy thread safety 'with' requestContext
Posted by Daniel Kulp <dk...@apache.org>.
Interesting patch
On Wednesday 30 January 2008, Tully, Gary wrote:
> 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().
Interesting solution. Basically, if a client does:
Map ctx = bp.getRequestContext();
ctx.put(...);
ctx.put(...);
ctx.put(...);
Things would be guaranteed safe. However, if they do:
bp.getRequestContext().put(....);
bp.getRequestContext().put(....);
bp.getRequestContext().put(....);
it wouldn't be. I'm actually OK with that. Very creative.
Dan
>On Wednesday 30 January 2008, Tully, Gary wrote:
> 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:dkulp@apache.org]
> > Sent: 23 January 2008 20:29
> > To: cxf-dev@incubator.apache.org
> > 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/cxf-user@incubator.apache.org/msg00150.h
> >tm
> >
> > >l [3]
> >
> > http://www.mail-archive.com/cxf-dev@incubator.apache.org/msg02914.ht
> >ml
> >
> > > [4] https://issues.apache.org/jira/browse/CXF-414
> > > [5]
> >
> > http://markmail.org/message/q2tx7ofm3lpqzjd6#query:+page:1+mid:vpwun
> >7x
> >
> > >xi 4r67ocv+state:results
> > > [6]
> >
> > http://lists.jboss.org/pipermail/jbossws-dev/2007-December/001096.ht
> >ml
> >
> > > ----------------------------
> > > 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
>
> ----------------------------
> 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
RE: JAXWS proxy thread safety 'with' requestContext
Posted by "Tully, Gary" <Ga...@iona.com>.
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:dkulp@apache.org]
> Sent: 23 January 2008 20:29
> To: cxf-dev@incubator.apache.org
> 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/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
>
----------------------------
IONA Technologies PLC (registered in Ireland)
Registered Number: 171387
Registered Address: The IONA Building, Shelbourne Road, Dublin 4, Ireland
Re: JAXWS proxy thread safety 'with' requestContext
Posted by Daniel Kulp <dk...@apache.org>.
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