Re: My XFire/CXF saga

2009-03-12 Thread Cornel Masson
As far as I know CXF does not use Apache HttpClient, but straight java.net.HttpUrlConnection? How many connections? How do you scale concurrency on that (I don't know, I've only ever used HttpClient)? Is it thread-safe? Daniel Kulp wrote: On Wed March 11 2009 10:49:28 am Benson Margulies wr

Re: My XFire/CXF saga

2009-03-11 Thread Daniel Kulp
On Wed March 11 2009 10:49:28 am Benson Margulies wrote: > My gut reaction is that this is not supposed to work. Synchronization > has overhead. If we put a synchronized(this) around the body of the > invocations, the single-threaded users pay the price and they don't > need it. If you do it, it's

Re: My XFire/CXF saga

2009-03-11 Thread Daniel Kulp
On Wed March 11 2009 6:47:21 am Cornel Masson wrote: > After much googling and fiddling I got no result, so I decided that the > best way forward was to replace XFire. Hoping that CXF would have fixed > all such problems, I ported to it. Hmm. Firstly, I couldn't generate the > Java classes because

Re: My XFire/CXF saga

2009-03-11 Thread Benson Margulies
My gut reaction is that this is not supposed to work. Synchronization has overhead. If we put a synchronized(this) around the body of the invocations, the single-threaded users pay the price and they don't need it. If you do it, it's three lines of code and all is well. However, I'm not the expert

Re: My XFire/CXF saga

2009-03-11 Thread Cornel Masson
Yes. Benson Margulies wrote: And you are using that client object, unprotected by a syncronization, in multiple threads? On Wed, Mar 11, 2009 at 10:32 AM, Cornel Masson wrote: My final solution uses the CXF Client (org.apache.cxf.endpoint.Client) directly, constructed using the Jax

Re: My XFire/CXF saga

2009-03-11 Thread Benson Margulies
And you are using that client object, unprotected by a syncronization, in multiple threads? On Wed, Mar 11, 2009 at 10:32 AM, Cornel Masson wrote: > My final solution uses the CXF Client (org.apache.cxf.endpoint.Client) > directly, constructed using the JaxWs Spring factory bean. > > class="or

Re: My XFire/CXF saga

2009-03-11 Thread Cornel Masson
My final solution uses the CXF Client (org.apache.cxf.endpoint.Client) directly, constructed using the JaxWs Spring factory bean. class="org.apache.cxf.jaxws.JaxWsClientFactoryBean" scope="prototype"> value="com.shazam.internal.recognition.webservices.v1.SIFoRInterface"/> Code: //"cxfC

Re: My XFire/CXF saga

2009-03-11 Thread Benson Margulies
While the original messsage is long, it doesn't contain the critical information. Exactly what combination of API and Spring (or lack of Spring) are you using to create the clients? What objects are you sharing between threads? On Wed, Mar 11, 2009 at 9:32 AM, Cornel Masson wrote: > I saw that

Re: My XFire/CXF saga

2009-03-11 Thread Cornel Masson
I saw that 'thread.local.request.context' property in the FAQ (http://cxf.apache.org/faq.html#FAQ-FrequentlyAskedQuestions) under "Are JAX-WS client proxies thread safe?". However, at the time it seemed to me it is only necessary to set that if my client code explicitly uses ((BindingProvider)p

Re: My XFire/CXF saga

2009-03-11 Thread Adrian Corcoran
There is a CXF property 'thread.local.request.context' that you can set to true when instantiating the client that will give each thread its own unique request context. This should eliminate your client side concurrency issues. On Wed, Mar 11, 2009 at 10:47 AM, Cornel Masson wrote: > Hi > > I wri

Re: My XFire/CXF saga

2009-03-11 Thread Edwin Quita
hi Cornel, i have not encountered any problems with CXF in terms of using wsdl2java here's a sample plugin configuration in my pom.xml file org.apache.cxf cx

My XFire/CXF saga

2009-03-11 Thread Cornel Masson
Hi I write this not as a flame, but as honest feedback, in the hope that there are perhaps solutions to some of these problems... We are replacing our core system with a solution that uses SOAP to talk to a gSOAP server. We were recommended XFire (this was before CXF existed), since it was s