Query About Request Context

[SantoshAkhilesh <sa...@huawei.com>]

Hi,
So far I had an idea that request context is put in thread local but I
realized it is not.

Why the request context is not threadlocal ?

If I want to send multiple client requests and each request having different
JMS header using same BindingProvider instance then do I need to synchronize
the context or not ?

I think now it needs to synchronized else it is overwritten by subsequent
calls.

Can anyone shed a light on this.

Regards,
Santosh

-- 
View this message in context: http://www.nabble.com/Query-About-Request-Context-tp15282233p15282233.html
Sent from the cxf-user mailing list archive at Nabble.com.

Re: Query About Request Context

[Willem Jiang <wi...@gmail.com>]

FYI,  currently we have some a JIRA[1] for tracing this issue.

https://issues.apache.org/jira/browse/CXF-1410


Willem.

SantoshAkhilesh wrote:
> Hi,
> So far I had an idea that request context is put in thread local but I
> realized it is not.
>
> Why the request context is not threadlocal ?
>
> If I want to send multiple client requests and each request having different
> JMS header using same BindingProvider instance then do I need to synchronize
> the context or not ?
>
> I think now it needs to synchronized else it is overwritten by subsequent
> calls.
>
> Can anyone shed a light on this.
>
> Regards,
> Santosh
>
>   

Re: Query About Request Context

[Daniel Kulp <dk...@apache.org>]

On Monday 04 February 2008, SantoshAkhilesh wrote:
> So far I had an idea that request context is put in thread local but I
> realized it is not.
>
> Why the request context is not threadlocal ?
>
> If I want to send multiple client requests and each request having
> different JMS header using same BindingProvider instance then do I
> need to synchronize the context or not ?
>
> I think now it needs to synchronized else it is overwritten by
> subsequent calls.
>
> Can anyone shed a light on this.

It's a spec compliance issue that we're still trying to battle with.   
Gery and I are trying to come up with a workable solution.  You can 
follow some of the thoughts at:
https://issues.apache.org/jira/browse/CXF-1410

Basically, a long long time ago, we DID use a ThreadLocal, but we could 
not get the TCK's to pass that way.   According to spec, context 
variables set on any thread need to be seen for all threads.   The main 
usage of this is in J2EE land if a proxy is injected into a another 
service via a @WebServiceReference or similar.   At @PostContruct time, 
the service may configure the ENDPOINT_URL or similar into the 
RequestContext, but that occurs on whatever thread is doing the deploy.   
However, later on, when that proxy is needed, its most likely being used 
on a different thread and if it's thread local, the ENDPOINT_URL setting 
is lost.   

Note: this is JAX-WS spec thing, note CXF.   Other JAX-WS impls have the 
same issue.  See:
http://lists.jboss.org/pipermail/jbossws-dev/2007-December/001096.html
http://lists.jboss.org/pipermail/jbossws-dev/2007-December/001094.html

Basically, digging into it, there doesn't seem to be anyway to make the 
getRequestContext be threadsafe by default without breaking spec 
compliance.    Gary and are looking into options to possibly set a 
property on the proxy to switch it to threadsafe mode or possibly a CXF 
specific getThreadLocalRequestContext() call or similar.    I'd welcome 
your input on the above JIRA to see what you think.

Thanks!

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

Re: Query About Request Context

[Willem Jiang <wi...@gmail.com>]

This link [1] may help your to get the whole story.
[1]http://www.nabble.com/Request-ResponseContext-of-JaxWsClientProxy-td10327781.html#a10335673

Willem.
Sky-Tiger wrote:
> See this:
>
> public class JaxWsClientProxy extends org.apache.cxf.frontend.ClientProxy
> implements
>     InvocationHandler, BindingProvider {
>
>     private static final Logger LOG =
> LogUtils.getL7dLogger(JaxWsClientProxy.class);
>
>     protected Map<String, Object> requestContext = new
> ConcurrentHashMap<String, Object>();
>
>     protected ThreadLocal <Map<String, Object>> responseContext =
>             new ThreadLocal<Map<String, Object>>();
>
>
> Anybody can tell me why responseContext  is threadlocal but requestContext 
> is not? That means BindingProvider  is not thread-safe!
>
> Is it a bug?
>   

Re: Query About Request Context

[Sky-Tiger <da...@gmail.com>]

See this:

public class JaxWsClientProxy extends org.apache.cxf.frontend.ClientProxy
implements
    InvocationHandler, BindingProvider {

    private static final Logger LOG =
LogUtils.getL7dLogger(JaxWsClientProxy.class);

    protected Map<String, Object> requestContext = new
ConcurrentHashMap<String, Object>();

    protected ThreadLocal <Map<String, Object>> responseContext =
            new ThreadLocal<Map<String, Object>>();


Anybody can tell me why responseContext  is threadlocal but requestContext 
is not? That means BindingProvider  is not thread-safe!

Is it a bug?
-- 
View this message in context: http://www.nabble.com/Query-About-Request-Context-tp15282233p15282508.html
Sent from the cxf-user mailing list archive at Nabble.com.