cxf-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Oliver Wulff <owu...@talend.com>
Subject AW: Proxy object used in multi threaded case
Date Fri, 18 Nov 2011 10:39:19 GMT
Maybe one other point to consider is the way how the IssuedTokenInterceptorProvider handles
the TokenStore...

    static final TokenStore getTokenStore(Message message) {
        EndpointInfo info = message.getExchange().get(Endpoint.class).getEndpointInfo();
        synchronized (info) {
            TokenStore tokenStore = (TokenStore)message.getContextualProperty(TokenStore.class.getName());
            if (tokenStore == null) {
                tokenStore = (TokenStore)info.getProperty(TokenStore.class.getName());
            }
            if (tokenStore == null) {
                tokenStore = new MemoryTokenStore();
                info.setProperty(TokenStore.class.getName(), tokenStore);
            }
            return tokenStore;
        }
    }

The TokenStore is tight to the proxy object / exchange object (CXF client) which means if
there is a pool of client objects I'd like to avoid that each uses its own TokenStore.

IMHO, the TokenStore should be global (tight to the bus) and get at invocation time a client
object of a pool for performance reasons.

Thanks
Oli
________________________________________
Von: Oliver Wulff [owulff@talend.com]
Gesendet: Freitag, 18. November 2011 09:00
Bis: users@cxf.apache.org
Betreff: AW: Proxy object used in multi threaded case

Can anybody give me a hint where to extend this functionality in CXF itself?

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}DoubleItTransportIONABSTPor
>>> t" createdFromAPI="true"> <jaxws:properties>
>>>            <entry key="ws-security.sts.client">
>>>                <bean class="org.apache.cxf.ws.security.trust.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_PROPERTY,
>>> "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
>>
>

Mime
View raw message