FYI, this timeout has a tomcat server error of "org.apache.cxf.binding.soap.SoapFault: Error reading XMLStreamReader." Which resulted from an empty soap body (as seen using the logging interceptor). I found similar errors after googling a bit.
It seems to be a mixture of spyware or faulty firewalls on the user's computers AND using mod JK on our server. We use Apache and Tomcat 6 connected with JK. I opened up the regular port 8080 on tomcat to bypass JK and then the affected user had no problems connecting! (after multiple reproducible failures only on their machine ONLY for certain service methods). So now we are slowly moving all our customers to use port 8080 bypassing JK until we can figure out what is really going on with JK. There are <10 users with this same problem, so I am attempting to pin-point the common thread between their machines (spyware, firewalls etc.), but that is still ongoing. Port 8080 seems to work fine though for everyone. I'll keep you posted with any further findings. This has been affecting us pretty badly for some time now ever since we upgraded from XFire. Kevin -----Original Message----- From: Daniel Kulp [mailto:dk...@apache.org] Sent: October-05-09 2:14 PM To: users@cxf.apache.org Cc: Kevin Priebe Subject: Re: Commons http client support? 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