Dear Wiki user, You have subscribed to a wiki page or wiki category on "Jakarta-httpclient Wiki" for change notification.
The following page has been changed by RolandWeber: http://wiki.apache.org/jakarta-httpclient/FrequentlyAskedConnectionManagementQuestions ------------------------------------------------------------------------------ - #pragma section-numbers 2 + #DEPRECATED - = Connection Management FAQ = + This page has been [http://wiki.apache.org/HttpComponents/FrequentlyAskedConnectionManagementQuestions moved] + to the new [http://wiki.apache.org/HttpComponents/ HttpComponents Wiki]. - This document addresses questions about connection management which - have been raised repeatedly on the HttpClient and HttpComponents mailing lists. - - ---- - [[TableOfContents]] - - - ------- - == Connections in TIME_WAIT State == - - After running your HTTP application, you use the [http://www.netstat.net/ netstat] command - and detect a lot of connections in state '''TIME_WAIT'''. - Now you wonder why these connections are not cleaned up. - - === What is the TIME_WAIT State? === - - The TIME_WAIT state is a protection mechanism in TCP. - The side that closes a socket connection orderly will keep the connection - in state TIME_WAIT for some time, typically between 1 and 4 minutes. - This happens ''after'' the connection is closed. It does ''not'' indicate a cleanup problem. - The TIME_WAIT state protects against loss of data and data corruption. - It is there to help you. For technical details, have a look at the - [http://www.softlab.ntua.gr/facilities/documentation/unix/unix-socket-faq/unix-socket-faq-2.html#ss2.7 Unix Socket FAQ, section 2.7]. - - === Some Connections Go To TIME_WAIT, Others Not === - - If a connection is orderly closed by your application, it will go to the TIME_WAIT state. - If a connection is orderly closed by the server, the server keeps it in TIME_WAIT and your client doesn't. - If a connection is reset or otherwise dropped by your application in a non-orderly fashion, - it will not go to TIME_WAIT. - - Unfortunately, it will not always be obvious to you whether a connection is closed orderly or not. - This is because connections are pooled and kept open for re-use by default. - !HttpClient 3.x, !HttpClient 4, and also the standard Java HttpURLConnection do that for you. - Most applications will simply execute requests, then read from the response stream, - and finally close that stream. - [[BR]] - Closing the response stream is ''not'' the same thing as closing the connection! - Closing the response stream returns the connection to the pool, but it will be kept open if possible. - This saves a lot of time if you send another request to the same host within a few seconds, or even minutes. - - Connection pools have a limited number of connections. - A pool may have 5 connections, or 100, or maybe only 1. - When you send a request to a host, and there is no open connection to that host in the pool, - a new connection needs to be opened. But if the pool is already full, - an open connection has to be closed before a new one can be opened. - In this case, the old connection will be closed orderly and go to the TIME_WAIT state. - [[BR]] - When your application exits and the JVM terminates, the open connections in the pools - will ''not'' be closed orderly. They are reset or cancelled, without going to TIME_WAIT. - To avoid this, you should call the {{{shutdown}}} method of the connection pools your - application is using before exiting. - The standard Java HttpURLConnection has no public method to shutdown it's connection pool. - - === Running Out Of Ports === - - Some applications open and orderly close a lot of connections within a short time, - for example when load-testing a server. A connection in state TIME_WAIT will prevent - that port number from being re-used for another connection. That is not an error, - it is the purpose of TIME_WAIT. - - TCP is configured at the operating system level, not through Java. - Your first action should be to increase the number of ephemeral ports on the machine. - Windows in particular has a rather low default for the ephemeral ports. - The [http://www.performancewiki.com/ PerformanceWiki] has tuning tips for the - common operating systems, have a look at the respective Network section. - [[BR]] - Only if increasing the number of ephemeral ports does not solve your problem, - you should consider decreasing the duration of the TIME_WAIT state. - You probably have to reduce the maximum lifetime of IP packets, as the duration - of TIME_WAIT is typically twice that timespan to allow for a round-trip delay. - Be aware that this will affect ''all'' applications running on the machine. - Don't ask us how to do it, we're not the experts for network tuning. - - There are some ways to deal with the problem at the application level. - One way is to send a "Connection: close" header with each request. - That will tell the server to close the connection, so it goes to TIME_WAIT on the other side. - Of course this also disables the keep-alive feature of connection pooling - and thereby degrades performance. If you are running load tests against a server, - the untypical behavior of your application may distort the test results. - [[BR] - Another way is to not orderly close connections. There is a trick to set - SO_LINGER to a special value, which will cause the connection to be reset - instead of orderly closed. Note that the !HttpClient API will not support that - directly, you'll have to extend or modify some classes to implement this hack. - [[BR]] - Yet another way is to re-use ports that are still blocked by a connection in TIME_WAIT. - You can do that by specifying the SO_REUSEADDR option when opening a socket. - Java 1.4 introduced the method - [http://java.sun.com/j2se/1.5.0/docs/api/java/net/Socket.html#setReuseAddress(boolean) Socket.setReuseAddress] - for this purpose. - You will have to extend or modify some classes of !HttpClient for this too, - but at least it's not a hack. - - === Further Reading === - - [http://www.softlab.ntua.gr/facilities/documentation/unix/unix-socket-faq/unix-socket-faq.html Unix Socket FAQ] - - [http://java.sun.com/j2se/1.5.0/docs/api/java/net/Socket.html#setReuseAddress(boolean) java.net.Socket.setReuseAddress] - - [http://www.nabble.com/HttpClient-3.1---JavaHttp-TIME_WAIT-differences-tf4951549.html Discussion] - on the !HttpClient mailing list in December 2007 - - [http://www.performancewiki.com/ PerformanceWiki] - - [http://www.netstat.net/ netstat] command line tool - --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
