On Thu October 29 2009 1:18:05 pm Kevin Priebe wrote: > Thanks Dan. That actually worked too! Before I had > httpClientPolicy.setAllowChunking(true); but I just commented that line out > while testing this and it still didn't work... I guess the default is true?
Yea. Default is true. It give us better performance and lower memory usage as we don't need to buffer anything. We can stream everything out directly, which is obviously good. Turning it off requires buffering so that a Content-Length can be computed. > I set it to false and it works fine even with mod_jk. I'm not sure why > bypassing mod_jk worked as well... but I like this solution better anyways. > Thanks, Sounds like mod_jk has issues with chunking. :-) Dan > Kevin > > > -----Original Message----- > From: Daniel Kulp [mailto:dk...@apache.org] > Sent: October-29-09 7:29 AM > To: users@cxf.apache.org > Cc: Kevin Priebe > Subject: Re: Commons http client support? > > > On thing you could try is turning off the chunking on the clients HTTP > conduits. Some proxy things have issues with chunking so turning it off > may > help. Not really sure, just a suggestion. > > Dan > > On Wed October 28 2009 7:22:19 pm Kevin Priebe wrote: > > 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
