cxf-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Oliver Wulff <owu...@talend.com>
Subject AW: AW: Proxy object used in multi threaded case
Date Mon, 21 Nov 2011 09:02:31 GMT
I was thinking in providing a pool of CXF client objects (not STS client objects).

IMHO, in general, I'd prefer to have no dependency whether a programmer uses one proxy instance
for all requests or a new one for each request. The creation if a proxy instance is "expensive"
(download wsdl from remote location, parsing (incl. policies), ...).

Therefore, I was thinking of a pool of CXF client objects (the parsed wsdl data could just
be cloned (in case not thread safe)). Then, it would be fine to have a non thread safe STSClient
also.

It should also address the other exceptions described here:
http://cxf.apache.org/faq#FAQ-AreJAXWSclientproxiesthreadsafe

Thanks
Oli
________________________________________
Von: Daniel Kulp [dkulp@apache.org]
Gesendet: Freitag, 18. November 2011 23:15
Bis: users@cxf.apache.org
Cc: Oliver Wulff
Betreff: Re: AW: Proxy object used in multi threaded case

On Friday, November 18, 2011 8:00:46 AM Oliver Wulff wrote:
> Can anybody give me a hint where to extend this functionality in CXF itself?

Well, I can give you workaround that should work with CXF right now:

Since the STSClient  is retrieved as a contextual property:
STSClient client = (STSClient)message
            .getContextualProperty(SecurityConstants.STS_CLIENT);

You can actually create a pool of STSClients and set that on the
RequestContext of the proxy or the message on a per-request basis.   For
example, an interceptor that runs before the IssuedTokenInterceptor could
checkout a STSClient from a pool, stick it on the message, and then add an
interceptor that runs later that sticks it back on the pool.  (and also in the
handleFault).    Thus, you can still have a single proxy, but multiple
STSClients.


Longer term, one thing we could do is make the call to getClient first do
something like:

STSClientFactory factory = message
            .getContextualProperty(SecurityConstants.STS_CLIENT_FACTORY);
if (factory != null) {
    client = factory.createClient(...);
} else {
    client = (STSClient)message
            .getContextualProperty(SecurityConstants.STS_CLIENT);
}

or similar to introduce some sort of factory in there.   We'd have to add a
"releaseClient" and add finally blocks in various places so the factory could
get re-called.  (or, on the STSClient itself, have a release() method that a
subclass could override to put it back in a pool)

Patch would be welcome.  :-)


Dan



>
> Thanks
> Oli
>
> ________________________________________
> Von: Oliver Wulff [owulff@talend.com]
> Gesendet: Mittwoch, 26. Oktober 2011 09:10
> Bis: users@cxf.apache.org
> Betreff: AW: Proxy object used in multi threaded case
>
> Hi there
>
> >> The SecureConv and IssuedToken interceptors current "sync" on the
> >> client
> >> object to make sure this case works.   It definitely can be a
> >> performance issue though.
>
> I guess you mean this:
>
>      STSClient client = STSUtils.getClient(message, "sts", itok);
>                         AddressingProperties maps =
>                             (AddressingProperties)message
>
> .get("javax.xml.ws.addressing.context.outbound"); if (maps == null) {
>                             maps = (AddressingProperties)message
>                                 .get("javax.xml.ws.addressing.context");
>                         }
>                         synchronized (client) {
>                             try {
>
>
> I was thinking of using Apache Commons Pool for the proxy objects. But
> before starting, I wanted to double check whether there are better ways
> thus I could contribute the enhancements back to the community. Maybe we
> could introduce a jaxws property for jaxws:client whether pooling should be
> used or not.
>
> What is the best place to hook this functionality in (ClientFactoryBean,
> ClientProxyFactoryBean or in the ClientProxy thus it works to inject the
> proxy object in your impl class)?
>
> Thanks
> Oli
> ________________________________________
> Von: Aki Yoshida [elakito@googlemail.com]
> Gesendet: Mittwoch, 19. Oktober 2011 23:57
> Bis: users@cxf.apache.org
> Betreff: Re: Proxy object used in multi threaded case
>
> 2011/10/19 Aki Yoshida <elakito@googlemail.com>:
> > 2011/10/19 Daniel Kulp <dkulp@apache.org>:
> >> On Wednesday, October 19, 2011 11:00:51 AM Oliver Wulff wrote:
> >>> Hi guys
> >>>
> >>> I've got a question with respect to a deployment of CXF in an
> >>> intermediary scenario. The service implementation of the
> >>> intermediary injects the proxy instance for the target service it
> >>> will call. Of course, this is a multi threaded environment where
> >>> the service implementation gets the current user as part of the
> >>> incoming message (not ws-security).
> >>>
> >>> The target service expects to get a security token issued by the
> >>> STS. The username is expected to be set for the proxy and the
> >>> WSSUsernameCallbackHandler is configured to get the user from there.
> >>>
> >>> Here a snippet of the configuration:
> >>>    <jaxws:client
> >>>
> >>> name="{http://www.example.org/contract/DoubleIt}DoubleItTransportION
> >>> ABSTPor t" createdFromAPI="true"> <jaxws:properties>
> >>>
> >>>            <entry key="ws-security.sts.client">
> >>>
> >>>                <bean
> >>>                class="org.apache.cxf.ws.security.tru
> >>>                st.STSClient">>>>
> >>>                    <constructor-arg ref="cxf"/>
> >>>                    <property name="onBehalfOf"
> >>>
> >>> ref="delegationCallbackHandler" />
> >>>
> >>>
> >>> The implementation of the intermediary service gets the
> >>> BindingProvider and adds the username like this:
> >>>
> >>> BindingProvider.getRequestcontext().put(BindingProvider.USERNAME_PRO
> >>> PERTY, "myuser)
> >>>
> >>> Has the request context the scope of the current thread or is it
> >>> tight to the proxy instance.
> >>
> >> This is answered in the FAQ:
> >>
> >> http://cxf.apache.org/faq#FAQ-AreJAXWSclientproxiesthreadsafe%3F
> >>
> >>> If latter, an intermediary must create a new proxy per
> >>> request. If the former, what is the scope of the STSClient instance?
> >>
> >> Per proxy.
> >
> > If your service implementation is using your proxy and the number of
> > actively used configurations is small, you can pool (or cache) your
> > proxy instances in your service so that you don't need to create a new
> > proxy per call.
> >
> > For other cases where there is no choice and there is only one proxy
> > instance, it would probably be nice if CXF can introduce an option to
> > make the request/response context objects thread-local. But this may
> > be more complicated and may have some adverse effect.
>
> I didn't see Dan's faq reference explaining that this thread-local
> option is already provided.
> so, please ignore my comment.
>
> regards, aki
>
> > regards, aki
> >
> >>> If
> >>> there are several requests coming in, the proxy instance is global,
> >>> the
> >>> request context is correlated with the thread (assumption) it might
> >>> not
> >>> work because there is only one STSClient instance.
> >>
> >> The SecureConv and IssuedToken interceptors current "sync" on the
> >> client
> >> object to make sure this case works.   It definitely can be a
> >> performance issue though.
> >>
> >>
> >> --
> >> Daniel Kulp
> >> dkulp@apache.org
> >> http://dankulp.com/blog
> >> Talend - http://www.talend.com
--
Daniel Kulp
dkulp@apache.org - http://dankulp.com/blog
Talend Community Coder - http://coders.talend.com

Mime
View raw message