I've been thinking about it for the following JAXRS-related issue be resolved : http://issues.apache.org/jira/browse/CXF-2321
However, as far as the CXF JAXRS is concerned there's a number of ways to indicate to the remote endpoint which HTTP verb has actually to be used so it's not a showstopper. IMHO, it could be worthwhile investigating the option of providing an Apache HTTPClient - based HttpConduit implementation, with a provided scope, such that a user does not have to code directly against Apache HTTPClient but through HttpConduit interface only...It can be quite a big effort though... cheers, Sergey Kevin Priebe wrote: > > Hi, > > > > I have been transitioning our users from our old XFire client to a new CXF > client over the past few months. I have been getting a lot more calls > lately about read timeouts (SOAPFaultException: Could not send Message. - > caused by - SocketTimeoutException: Read timed out). Here are my > observations: > > > > - The users were successfully using the XFire client, and as soon > as they start using the CXF client, they seem to randomly get these > errors. > > - Reverting to the old XFire client works fine for these users > with > no problems > > - Both web services are on the same server, running in the same > tomcat instance - no other changes were made > > - It affects Satellite Internet users more, but also happens to > fast Cable Internet users > > - A ping to our server for a Satellite user was always less than > 2 > seconds, which is far less than the read timeout > > - Read timeout is set to 30 seconds - all requests are simple and > should be fast - less than 5 seconds for sure > > - I have increased the timeout to 60 seconds, but got the same > behaviour - either it successfully connects within seconds, or never does. > The timeout just seems to delay the error... > > - I have experienced this problem when connecting to the live > server myself, but only 2-3 times in the last few months. > > > > XFire just seems a little more resilient to connection problems than CXF. > Perhaps this is because it uses the Apache commons httpclient? > > > > Are there any plans to use the commons httpclient in CXF? I found this > old > open issue https://issues.apache.org/jira/browse/CXF-291 which appears to > have been forgotten. The description says it shouldn't be hard to > integrate. I even started looking into doing it myself, but am not sure I > have time. If anyone has any pointers or partial code, that would be > helpful. > > > > Thank you for any help or insight as to why this might be happening and > how > to fix it. If you need additional information, let me know. We are using > a > pretty basic setup with the tomcat CXF servlet and JaxWS. We are using > the > GZip feature, and the following client policy config: > > > > httpClientPolicy.setConnectionTimeout(30000); > > httpClientPolicy.setReceiveTimeout(30000); > > httpClientPolicy.setAllowChunking(true); > > httpClientPolicy.setAutoRedirect(true); > > httpClientPolicy.setMaxRetransmits(3); > > > > I have tried disabling GZip and changing all the above settings, with no > luck. > > > > Kevin > > > > > -- View this message in context: http://www.nabble.com/Commons-http-client-support--tp25754589p25756999.html Sent from the cxf-user mailing list archive at Nabble.com.
