You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@cxf.apache.org by venkatesham nalla <v_...@hotmail.com> on 2016/11/01 21:04:04 UTC
JAX-WS Service or Port cache?
Hi,
Is it a good idea to cache the CXF Service or Port instance on client side for later use, to avoid creating the service from WSDL every time? What are the disadvantages of caching?
thanks,
Venkat
Re: JAX-WS Service or Port cache?
Posted by Claude Libois <cl...@gmail.com>.
Quote from the CXF FAQ:
http://cxf.apache.org/faq.html#FAQ-AreJAX-WSclientproxiesthreadsafe?
Are JAX-WS client proxies thread safe?
*Official JAX-WS answer:* No. According to the JAX-WS spec, the client
proxies are NOT thread safe. To write portable code, you should treat them
as non-thread safe and synchronize access or use a pool of instances or
similar.
*CXF answer:* CXF proxies are thread safe for MANY use cases. The
exceptions are:
-
Use of ((BindingProvider)proxy).getRequestContext() - per JAX-WS spec,
the request context is PER INSTANCE. Thus, anything set there will affect
requests on other threads. With CXF, you can do:
((BindingProvider)proxy).getRequestContext().put(
"thread.local.request.context", "true");
and future calls to getRequestContext() will use a thread local request
context. That allows the request context to be threadsafe. (Note: the
response context is always thread local in CXF)
- Settings on the conduit - if you use code or configuration to directly
manipulate the conduit (like to set TLS settings or similar), those are not
thread safe. The conduit is per-instance and thus those settings would be
shared. Also, if you use the FailoverFeature and LoadBalanceFeatures, the
conduit is replaced on the fly. Thus, settings set on the conduit could get
lost before being used on the setting thread.
- Session support - if you turn on sessions support (see jaxws spec),
the session cookie is stored in the conduit. Thus, it would fall into the
above rules on conduit settings and thus be shared across threads.
- WS-Security tokens - If use WS-SecureConversation or WS-Trust, the
retrieved token is cached in the Endpoint/Proxy to avoid the extra (and
expensive) calls to the STS to obtain tokens. Thus, multiple threads will
share the token. If each thread has different security credentials or
requirements, you need to use separate proxy instances.
For the conduit issues, you COULD install a new ConduitSelector that uses a
thread local or similar. That's a bit complex though.
For most "simple" use cases, you can use CXF proxies on multiple threads.
The above outlines the workarounds for the others.
2016-11-02 8:22 GMT+01:00 Claude Libois <cl...@gmail.com>:
> Just make sur that everything is thread safe. I did the same as you while
> using Axis(for same reason) but some method weren't thread safe... So I
> have finally put it in a thread variable.
> Best Regards,
> Claude
>
>
> 2016-11-01 23:26 GMT+01:00 Christian Schneider <ch...@die-schneider.net>:
>
>> I typically inject the proxy by interface into the business code. This
>> makes sure the business code is independent of CXF and easier to test.
>> This also makes the individual service calls faster than recreating the
>> proxy every time.
>>
>> So I think there is nothing wrong with caching the proxy instance.
>>
>> Christian
>>
>>
>> On 01.11.2016 22:04, venkatesham nalla wrote:
>>
>>> Hi,
>>>
>>>
>>> Is it a good idea to cache the CXF Service or Port instance on client
>>> side for later use, to avoid creating the service from WSDL every time?
>>> What are the disadvantages of caching?
>>>
>>>
>>> thanks,
>>>
>>> Venkat
>>>
>>>
>>>
>>
>> --
>> Christian Schneider
>> http://www.liquid-reality.de
>>
>> Open Source Architect
>> http://www.talend.com
>>
>>
>
Re: JAX-WS Service or Port cache?
Posted by Claude Libois <cl...@gmail.com>.
Just make sur that everything is thread safe. I did the same as you while
using Axis(for same reason) but some method weren't thread safe... So I
have finally put it in a thread variable.
Best Regards,
Claude
2016-11-01 23:26 GMT+01:00 Christian Schneider <ch...@die-schneider.net>:
> I typically inject the proxy by interface into the business code. This
> makes sure the business code is independent of CXF and easier to test.
> This also makes the individual service calls faster than recreating the
> proxy every time.
>
> So I think there is nothing wrong with caching the proxy instance.
>
> Christian
>
>
> On 01.11.2016 22:04, venkatesham nalla wrote:
>
>> Hi,
>>
>>
>> Is it a good idea to cache the CXF Service or Port instance on client
>> side for later use, to avoid creating the service from WSDL every time?
>> What are the disadvantages of caching?
>>
>>
>> thanks,
>>
>> Venkat
>>
>>
>>
>
> --
> Christian Schneider
> http://www.liquid-reality.de
>
> Open Source Architect
> http://www.talend.com
>
>
Re: JAX-WS Service or Port cache?
Posted by Christian Schneider <ch...@die-schneider.net>.
I typically inject the proxy by interface into the business code. This
makes sure the business code is independent of CXF and easier to test.
This also makes the individual service calls faster than recreating the
proxy every time.
So I think there is nothing wrong with caching the proxy instance.
Christian
On 01.11.2016 22:04, venkatesham nalla wrote:
> Hi,
>
>
> Is it a good idea to cache the CXF Service or Port instance on client side for later use, to avoid creating the service from WSDL every time? What are the disadvantages of caching?
>
>
> thanks,
>
> Venkat
>
>
--
Christian Schneider
http://www.liquid-reality.de
Open Source Architect
http://www.talend.com