I don't use HttpClient, directly, but if I'm not mistaking, javax.mail.jar (JavaMail) and Google Calendar API uses HttpClient, and I use JavaMail and Google Calendar API, directly, in my app.
Google Calendar API seemed to always close their connections and I have even experienced downtime (host unknown and/or server error responses from Google Calendar API service), and I have experienced downtime (unknown host exceptions) when using JavaMail to connect to GMAIL (via IMAP connection) to check-for-and-download emails. Some months ago, I recognized that I had many unclosed connections on my Windows Server 2008 production server, where Tomcat was running my app. Instead of blame Tomcat, I listened in on Tomcat user list and I searched the internet, and learned that the unclosed connections were due to my inexperience (using JavaMail), so I refactored my code and closed my JavaMail IMAP connection when checking-and-downloading emails from GMAIL (google) servers. I just searched google, stackoverflow tomcat httpclient timeout[1] and found the following: Best Practice to Use HttpClient in Multithreaded Environment[2] Using Apache HttpClient how to set the TIMEOUT on a request and response[3] and many more search results (and related links) that you can read. [1] http://lmgtfy.com/?q=stackoverflow+tomcat+httpclient+timeout [2] http://stackoverflow.com/questions/1281219/best-practice-to-use-httpclient-in-multithreaded-environment [3] http://stackoverflow.com/questions/9873810/using-apache-httpclient-how-to-set-the-timeout-on-a-request-and-response On Fri, May 17, 2013 at 8:02 AM, Paolo Botta <paolo.bo...@cabril.it> wrote: > Sorry for the question, but if I set the timeout on the HttpClient I force > the client to close the connection after the timeout, but have I informed > the server that there is a timeout, so the server close the connection > after > the timeout? I mean HttpClient tells to the server about the timeout? > > Thx > Paolo > > -----Messaggio originale----- > Da: chk...@gmail.com [mailto:chk...@gmail.com] Per conto di Christian > Kaltepoth > Inviato: venerdì 17 maggio 2013 13:30 > A: Tomcat Users List > Oggetto: Re: Tomcat hangs every day > > Hey, > > I'm also not an expert for HttpClient, but when creating connections to > remote services it is usually a good idea to set connection timeouts and > socket timeouts so that the client doesn't block forever if there are > problems with the connection. Exactly this seems to be the problem in your > case. > > Best regards > > Christian Kaltepoth > > > > > 2013/5/17 Sascha Troll <sascha.tr...@geberit.com> > > > Christian, > > > > thanks for this. > > > > Can you give me a hint. I am just the server guy, so I can tell the > > developer. > > > > Thanks a lot ! > > > > Sascha > > > > > > > > From: Christian Kaltepoth <christ...@kaltepoth.de> > > To: Tomcat Users List <users@tomcat.apache.org> > > Date: 17.05.2013 11:24 > > Subject: Re: Tomcat hangs every day > > Sent by: chk...@gmail.com > > > > > > > > Seems like you have a class called SearchClientRemoteClient which uses > > HTTPClient. Many threads seems to wait for remote responses. I guess > > you don't set any timeouts for the HTTPClient and therefore many > > threads hang in HttpClient.executeMethod() forever. You should ALWAYS > > set timeouts when using HTTPClient. :) > > > > I hope this helps :) > > > > Christian > > > > > > 2013/5/17 Sascha Troll <sascha.tr...@geberit.com> > > > > > Hi ! > > > > > > I have problem with our Tomcat 7.0.40 (upgrade already done from > > > 7.0.39 and 7.0.37 and still the same issue). > > > > > > Its still running, but not longer accepting any connection on port > 8080. > > > > > > Attached are the thread dumps which were created this morning when > > > the server was not longer available. > > > I cannot find any deadlocks and need some help to find the cause. > > > > > > > > > > > > Thanks > > > Sascha > > > > > > > > > > > > > > > > ---------------------------------------------------------------------- > > ---------------------------- > > > Disclaimer: > > > The content of this e-mail (including attachments) is confidential > > > and intended for the use of the addressee only. If you are not the > > > intended recipient please delete the e-mail; dissemination or > > > disclosure of its content to anyone is strictly prohibited! > > > Before opening an attachment please check it for viruses. We accept > > > no liability for any damage caused by viruses. > > > > > > -------------------------------------------------------------------- > > > - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org > > > For additional commands, e-mail: users-h...@tomcat.apache.org > > > > > > > > > > > -- > > Christian Kaltepoth > > Blog: http://blog.kaltepoth.de/ > > Twitter: http://twitter.com/chkal > > GitHub: https://github.com/chkal > > > > > > > > > > > > > > ---------------------------------------------------------------------- > > ---------------------------- > > Disclaimer: > > The content of this e-mail (including attachments) is confidential and > > intended for the use of the addressee only. If you are not the > > intended recipient please delete the e-mail; dissemination or > > disclosure of its content to anyone is strictly prohibited! > > Before opening an attachment please check it for viruses. We accept no > > liability for any damage caused by viruses. > > > > > > -- > Christian Kaltepoth > Blog: http://blog.kaltepoth.de/ > Twitter: http://twitter.com/chkal > GitHub: https://github.com/chkal > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org > For additional commands, e-mail: users-h...@tomcat.apache.org > >
