Return-Path: X-Original-To: apmail-cxf-users-archive@www.apache.org Delivered-To: apmail-cxf-users-archive@www.apache.org Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by minotaur.apache.org (Postfix) with SMTP id E114C7E39 for ; Mon, 21 Nov 2011 09:03:02 +0000 (UTC) Received: (qmail 79346 invoked by uid 500); 21 Nov 2011 09:03:02 -0000 Delivered-To: apmail-cxf-users-archive@cxf.apache.org Received: (qmail 79298 invoked by uid 500); 21 Nov 2011 09:03:02 -0000 Mailing-List: contact users-help@cxf.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: users@cxf.apache.org Delivered-To: mailing list users@cxf.apache.org Received: (qmail 79290 invoked by uid 99); 21 Nov 2011 09:03:02 -0000 Received: from athena.apache.org (HELO athena.apache.org) (140.211.11.136) by apache.org (qpsmtpd/0.29) with ESMTP; Mon, 21 Nov 2011 09:03:01 +0000 X-ASF-Spam-Status: No, hits=0.7 required=5.0 tests=RCVD_IN_DNSWL_NONE,SPF_NEUTRAL X-Spam-Check-By: apache.org Received-SPF: neutral (athena.apache.org: local policy) Received: from [64.95.72.241] (HELO mxout.myoutlookonline.com) (64.95.72.241) by apache.org (qpsmtpd/0.29) with ESMTP; Mon, 21 Nov 2011 09:02:56 +0000 Received: from mxout.myoutlookonline.com (localhost [127.0.0.1]) by mxout.myoutlookonline.com (Postfix) with ESMTP id 067EF8BF0E4; Mon, 21 Nov 2011 04:02:34 -0500 (EST) X-Virus-Scanned: by SpamTitan at mail.lan Received: from S10HUB002.SH10.lan (unknown [10.110.2.1]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by mxout.myoutlookonline.com (Postfix) with ESMTPS id 599858BF1C0; Mon, 21 Nov 2011 04:02:33 -0500 (EST) Received: from S10BE002.SH10.lan ([::1]) by S10HUB002.SH10.lan ([::1]) with mapi id 14.01.0289.001; Mon, 21 Nov 2011 04:02:33 -0500 From: Oliver Wulff To: Daniel Kulp , "users@cxf.apache.org" Subject: AW: AW: Proxy object used in multi threaded case Thread-Topic: AW: Proxy object used in multi threaded case Thread-Index: AcyOOcoAkPbj0eMWST6aNYDQWhOhUAAcPeSAAAga/AAAABhwAAE4VQFjBIbF4R4AKGLaAABwBNXm Date: Mon, 21 Nov 2011 09:02:31 +0000 Message-ID: <79AB4452999C844D9920E036353327310EB8A5@S10BE002.SH10.lan> References: <79AB4452999C844D9920E036353327310D3EA5@S10BE002.SH10.lan> <79AB4452999C844D9920E036353327310D67EB@S10BE002.SH10.lan> <79AB4452999C844D9920E036353327310E91F9@S10BE002.SH10.lan>,<3484921.ZY5TOetGLg@dilbert.dankulp.com> In-Reply-To: <3484921.ZY5TOetGLg@dilbert.dankulp.com> Accept-Language: de-DE, en-US Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [195.28.224.59] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 I was thinking in providing a pool of CXF client objects (not STS client ob= jects).=0A= =0A= IMHO, in general, I'd prefer to have no dependency whether a programmer use= s one proxy instance for all requests or a new one for each request. The cr= eation if a proxy instance is "expensive" (download wsdl from remote locati= on, parsing (incl. policies), ...).=0A= =0A= 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 fin= e to have a non thread safe STSClient also.=0A= =0A= It should also address the other exceptions described here:=0A= http://cxf.apache.org/faq#FAQ-AreJAXWSclientproxiesthreadsafe=0A= =0A= Thanks=0A= Oli=0A= ________________________________________=0A= Von: Daniel Kulp [dkulp@apache.org]=0A= Gesendet: Freitag, 18. November 2011 23:15=0A= Bis: users@cxf.apache.org=0A= Cc: Oliver Wulff=0A= Betreff: Re: AW: Proxy object used in multi threaded case=0A= =0A= On Friday, November 18, 2011 8:00:46 AM Oliver Wulff wrote:=0A= > Can anybody give me a hint where to extend this functionality in CXF itse= lf?=0A= =0A= Well, I can give you workaround that should work with CXF right now:=0A= =0A= Since the STSClient is retrieved as a contextual property:=0A= STSClient client =3D (STSClient)message=0A= .getContextualProperty(SecurityConstants.STS_CLIENT);=0A= =0A= You can actually create a pool of STSClients and set that on the=0A= RequestContext of the proxy or the message on a per-request basis. For=0A= example, an interceptor that runs before the IssuedTokenInterceptor could= =0A= checkout a STSClient from a pool, stick it on the message, and then add an= =0A= interceptor that runs later that sticks it back on the pool. (and also in = the=0A= handleFault). Thus, you can still have a single proxy, but multiple=0A= STSClients.=0A= =0A= =0A= Longer term, one thing we could do is make the call to getClient first do= =0A= something like:=0A= =0A= STSClientFactory factory =3D message=0A= .getContextualProperty(SecurityConstants.STS_CLIENT_FACTORY);= =0A= if (factory !=3D null) {=0A= client =3D factory.createClient(...);=0A= } else {=0A= client =3D (STSClient)message=0A= .getContextualProperty(SecurityConstants.STS_CLIENT);=0A= }=0A= =0A= or similar to introduce some sort of factory in there. We'd have to add a= =0A= "releaseClient" and add finally blocks in various places so the factory cou= ld=0A= get re-called. (or, on the STSClient itself, have a release() method that = a=0A= subclass could override to put it back in a pool)=0A= =0A= Patch would be welcome. :-)=0A= =0A= =0A= Dan=0A= =0A= =0A= =0A= >=0A= > Thanks=0A= > Oli=0A= >=0A= > ________________________________________=0A= > Von: Oliver Wulff [owulff@talend.com]=0A= > Gesendet: Mittwoch, 26. Oktober 2011 09:10=0A= > Bis: users@cxf.apache.org=0A= > Betreff: AW: Proxy object used in multi threaded case=0A= >=0A= > Hi there=0A= >=0A= > >> The SecureConv and IssuedToken interceptors current "sync" on the=0A= > >> client=0A= > >> object to make sure this case works. It definitely can be a=0A= > >> performance issue though.=0A= >=0A= > I guess you mean this:=0A= >=0A= > STSClient client =3D STSUtils.getClient(message, "sts", itok);=0A= > AddressingProperties maps =3D=0A= > (AddressingProperties)message=0A= >=0A= > .get("javax.xml.ws.addressing.context.outbound"); if (maps =3D=3D null) {= =0A= > maps =3D (AddressingProperties)message=0A= > .get("javax.xml.ws.addressing.context");= =0A= > }=0A= > synchronized (client) {=0A= > try {=0A= >=0A= >=0A= > I was thinking of using Apache Commons Pool for the proxy objects. But=0A= > before starting, I wanted to double check whether there are better ways= =0A= > thus I could contribute the enhancements back to the community. Maybe we= =0A= > could introduce a jaxws property for jaxws:client whether pooling should = be=0A= > used or not.=0A= >=0A= > What is the best place to hook this functionality in (ClientFactoryBean,= =0A= > ClientProxyFactoryBean or in the ClientProxy thus it works to inject the= =0A= > proxy object in your impl class)?=0A= >=0A= > Thanks=0A= > Oli=0A= > ________________________________________=0A= > Von: Aki Yoshida [elakito@googlemail.com]=0A= > Gesendet: Mittwoch, 19. Oktober 2011 23:57=0A= > Bis: users@cxf.apache.org=0A= > Betreff: Re: Proxy object used in multi threaded case=0A= >=0A= > 2011/10/19 Aki Yoshida :=0A= > > 2011/10/19 Daniel Kulp :=0A= > >> On Wednesday, October 19, 2011 11:00:51 AM Oliver Wulff wrote:=0A= > >>> Hi guys=0A= > >>>=0A= > >>> I've got a question with respect to a deployment of CXF in an=0A= > >>> intermediary scenario. The service implementation of the=0A= > >>> intermediary injects the proxy instance for the target service it=0A= > >>> will call. Of course, this is a multi threaded environment where=0A= > >>> the service implementation gets the current user as part of the=0A= > >>> incoming message (not ws-security).=0A= > >>>=0A= > >>> The target service expects to get a security token issued by the=0A= > >>> STS. The username is expected to be set for the proxy and the=0A= > >>> WSSUsernameCallbackHandler is configured to get the user from there.= =0A= > >>>=0A= > >>> Here a snippet of the configuration:=0A= > >>> >>>=0A= > >>> name=3D"{http://www.example.org/contract/DoubleIt}DoubleItTransportIO= N=0A= > >>> ABSTPor t" createdFromAPI=3D"true"> =0A= > >>>=0A= > >>> =0A= > >>>=0A= > >>> >>> class=3D"org.apache.cxf.ws.security.tru=0A= > >>> st.STSClient">>>>=0A= > >>> =0A= > >>> >>>=0A= > >>> ref=3D"delegationCallbackHandler" />=0A= > >>>=0A= > >>>=0A= > >>> The implementation of the intermediary service gets the=0A= > >>> BindingProvider and adds the username like this:=0A= > >>>=0A= > >>> BindingProvider.getRequestcontext().put(BindingProvider.USERNAME_PRO= =0A= > >>> PERTY, "myuser)=0A= > >>>=0A= > >>> Has the request context the scope of the current thread or is it=0A= > >>> tight to the proxy instance.=0A= > >>=0A= > >> This is answered in the FAQ:=0A= > >>=0A= > >> http://cxf.apache.org/faq#FAQ-AreJAXWSclientproxiesthreadsafe%3F=0A= > >>=0A= > >>> If latter, an intermediary must create a new proxy per=0A= > >>> request. If the former, what is the scope of the STSClient instance?= =0A= > >>=0A= > >> Per proxy.=0A= > >=0A= > > If your service implementation is using your proxy and the number of=0A= > > actively used configurations is small, you can pool (or cache) your=0A= > > proxy instances in your service so that you don't need to create a new= =0A= > > proxy per call.=0A= > >=0A= > > For other cases where there is no choice and there is only one proxy=0A= > > instance, it would probably be nice if CXF can introduce an option to= =0A= > > make the request/response context objects thread-local. But this may=0A= > > be more complicated and may have some adverse effect.=0A= >=0A= > I didn't see Dan's faq reference explaining that this thread-local=0A= > option is already provided.=0A= > so, please ignore my comment.=0A= >=0A= > regards, aki=0A= >=0A= > > regards, aki=0A= > >=0A= > >>> If=0A= > >>> there are several requests coming in, the proxy instance is global,= =0A= > >>> the=0A= > >>> request context is correlated with the thread (assumption) it might= =0A= > >>> not=0A= > >>> work because there is only one STSClient instance.=0A= > >>=0A= > >> The SecureConv and IssuedToken interceptors current "sync" on the=0A= > >> client=0A= > >> object to make sure this case works. It definitely can be a=0A= > >> performance issue though.=0A= > >>=0A= > >>=0A= > >> --=0A= > >> Daniel Kulp=0A= > >> dkulp@apache.org=0A= > >> http://dankulp.com/blog=0A= > >> Talend - http://www.talend.com=0A= --=0A= Daniel Kulp=0A= dkulp@apache.org - http://dankulp.com/blog=0A= Talend Community Coder - http://coders.talend.com=0A=