On Wed, 2010-07-21 at 18:36 +0300, Casei Marat wrote: > Hi folks, > > Our app is leaking socket descriptors heavily, and we have isolated > the offending code to the piece that is using HttpCore/HttpClient > (we're using 4.0). > > Here are the leaks: > > # /usr/sbin/lsof -p 1979 | grep sock > java 1979 tomcat 15u sock 0,5 6794 > can't identify protocol > java 1979 tomcat 76u sock 0,5 17237 > can't identify protocol > java 1979 tomcat 82u sock 0,5 6843 > can't identify protocol > java 1979 tomcat 84u sock 0,5 17586 > can't identify protocol > java 1979 tomcat 86u sock 0,5 17236 > can't identify protocol > java 1979 tomcat 91u sock 0,5 18457 > can't identify protocol > java 1979 tomcat 92u sock 0,5 10816 > can't identify protocol > java 1979 tomcat 93u sock 0,5 10817 > can't identify protocol > ... > java 1979 tomcat 838u sock 0,5 54819 > can't identify protocol > java 1979 tomcat 839u sock 0,5 54820 > can't identify protocol > java 1979 tomcat 840u sock 0,5 54821 > can't identify protocol > java 1979 tomcat 842u sock 0,5 58989 > can't identify protocol > > These sockets point to an unknown device "0,5". Originally they've > been an https connection, as can be seen: > > java 1979 tomcat 1015u IPv6 84662 TCP > 10.xxx.xxx.xxx:zzzzz->10.xxx.xxx.xxx:https (ESTABLISHED) > ... [couple of mins later] ... > java 1979 tomcat 1015u sock 0,5 84662 > can't identify protocol > > This may or may not be related to JDK bug that is discussed in this thread: > http://mail-archives.apache.org/mod_mbox/hc-dev/201007.mbox/%[email protected]%3e >
It is not. HttpClient does not make use of NIO based components. > We're using JDK on Linux. The app opens connections to an > "Apache/1.3.33 (Unix) mod_ssl/2.8.22 OpenSSL/0.9.7e" server and parses > responses. The client (DefaultHttpClient created with > ThreadSafeClientConnManager) is cached then for reuse, and may expire. > At some stage it may be invoked again and throw an exception, where it > will be evoked from the cache and collected by GC. > > Any ideas? > (1) It is more likely that your application is leaking connections rather than HttpClient leaking socket descriptors. You can check the state of the connection pool by turning on the context logging. (2) Make sure to _always_ shut down the connection manager when it is no longer needed. Oleg --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
