I'm definitely not sure what would be causing that sort of timeout. Strange.
I did look a little into doing an http-client based conduit, but it's not exactly an easy task. The API's are pretty much backwords from HTTPUrlConnection which makes mapping it hard. Basically, the URLConnection gives you an OutputStream that you write to as need to. With http-client, you provide an object that it calls with the Outputstream when IT wants you to. Thus, we would need to do some fancy PhaseInterceptorChain pause/resume/reenter things to get it to still stream. Either that or just don't stream which is another option. HTTPs is another whole HUGE HUGE issue. Mapping all the CXF https options onto http-client is not easy, and in some cases, not possible due to missing stuff in http-client (although that investigation was against http-client 3, not 4 so things have possibly changed). Anyway, from my personal perspective, it just hasn't been enough of a priority to really start it. The customers I have dealt with haven't really hit any issues with the current conduit to justify the amount of work to do this. That said, if I was to start the work, I'd really suggest a layered approach of subclassing the current conduit and just invoke the http-client stuff in the "known cases" where it would work well. Example: allow the existing code to handle https for now, only use http-conduit if streaming is turned off anyway (no chunking), etc... Then expand out from there. Dan On Mon October 5 2009 1:01:09 pm 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 > -- Daniel Kulp dk...@apache.org http://www.dankulp.com/blog
