Hello Dan, thanks for your help. You seem to be the man for CXF ;-). I use the HttpConduit now to set the request timeout and therefore create a new client for each request. As the WSDL gets cached in a map I hope the performence overhead is okay. I will monitor our server to see if we run into problems and maybe introduce some sort of pool later. If someone has another solution for this or a good hint how to create a pool for CXF feel free to add it to this thread. But problem solved.
Kind regards Tom -----Ursprüngliche Nachricht----- Von: "Daniel Kulp" <[email protected]> Gesendet: Feb 3, 2012 8:28:22 PM An: [email protected] Betreff: Re: thread safety (post FAQ) >On Thursday, February 02, 2012 3:35:36 PM [email protected] wrote: >> Dear experienced cxf users, >> >> I’m working with cxf for the first time and have issues to determine how to >> ensure thread safety. I have read the FAQ but am not sure what’s exactly >> the “client”. >> *** The facts: >> ----------------------- >> I want to call a web service (my code is the client) from a server system >> -> Therefore I have multiple requests and threads. >> I want to set the timeout for the call >> -> Therefore if have to use ((BindingProvider) >> authPortType1).getRequestContext().put(JAXWSProperties.CONNECT_TIMEOUT, 1 * >> 60 * 1000); > >Well, JAXWSProperties.CONNECT_TIMEOUT is not a CXF property. That is likely a >Metro property and not something we support. Thus, that won't work with CXF >anyway. > > >> *** The questions: >> ----------------------- >> 1.) How can I achieve this thread safety? >> a) I could set >> ((BindingProvider)myPortType).getRequestContext().put("thread.local.request >> .context", "true"); but that would make it risky if someone is using the >> HttpConduit Object later. > >Correct. If you add settings directly to the conduit, that would affect >things. > >> b) I could create a new client each time but that >> would be expensive, depending on question > >Agreed. You could create a pool of them to minimize that. > > >> 2.)What is the first object that is not thread safe? > >Well, the request context, but the setting above changes that. > >> The ‘service’-class? >> The object implementing the PortType interface? > >Really, its the context and the conduit. You *could* implement your own >ConduitSelector that returns a unique conduit each time. That really wouldn't >be that expensive, I think. Not 100% sure though. > >That said, I'm pretty sure you can create a unique "per request" >HTTPClientPolicy object and set that on the context via: > >((BindingProvider)authPortType1).getRequestContext() > .put(HTTPClientPolicy.class.getName(), policy) > >and that would be picked up. > > >> Do I have to parse the WSDL >> each time I want a new client object? > >Yes and no. The WSDLManager does cache the WSDL's so if something has caused >the wsdl to remain, it may not need to be re-parsed. > >> 3.) What is ClientProxy.getClient() for? Does it create a new object? A new >> client? Is this the solution to thread safety? ;-) > >Returns the internal CXF Client object. The object (authPortType1 in your >case) is just a JDK proxy around an InvokationHandler that calls into the >Client object. The getClient() call just allows access to the Client >object. > > > >> >> Any help would be nice. Thanks in advance. >> >> Best regards >> Tom >> ___________________________________________________________ >> SMS schreiben mit WEB.DE FreeMail - einfach, schnell und >> kostenguenstig. Jetzt gleich testen! http://f.web.de/?mc=021192 >-- >Daniel Kulp >[email protected] - http://dankulp.com/blog >Talend Community Coder - http://coders.talend.com ___________________________________________________________ SMS schreiben mit WEB.DE FreeMail - einfach, schnell und kostenguenstig. Jetzt gleich testen! http://f.web.de/?mc=021192
