TCP connections

If both a client and server simultaneously close a connection there is a race condition that may result in the connection hanging and not closing for minutes. Both sides of the connection may simultaneously send a FIN to the other side and both may end up waiting for an ACK or RST until the default TCP timeout; which is typically double MSL (maximum segment life time) or 4 minutes.

Having the client do a read until EOF is signaled before closing avoids the issue.

RFC 793 [Postel 1981] specifies the MSL as 2 minutes. Common implementation values, however, are 30 seconds, 1 minute and 2 minutes.

Description and diagrams of why simultaneous close results in time-wait

TCP state and sequence diagrams showing how and why the simultaneous close results in long timeouts

TCP protocol diagram including simultaneous close

SO_LINGER


From here:

The tcp_close_wait_interval is 4 minutes. This variable defines how long a host would wait in the TIME_WAIT state. This implies that the host which is still up tries to send packets over the TCP connection to the down host. If it doesn't get any replies it moves into this TIME_WAIT state for 4 minutes before it closes the socket.

By default, it could theoretically stay up forever. However, when a socket is created, you could give it the SO_KEEPALIVE option, which would send a keepalive according to the value tcp_keepalive_interval which defaults to 2 hours.

So if SO_KEEPALIVE is set the answer is 2 hours by default, if
not the socket could stay open indefinitely.

Comments

Post a Comment

Popular posts from this blog

Sites, Newsletters, and Blogs

BLOGS Java.net Weblogs Martin Fowler's blog Paul Graham Ruminations of a Programmer Form Follows Function Newsletters Core Java Tech Tips Enterprise Java Tech Tips JavaSpecialists.EU TheServerSide.com Sites Java.net Today Hot Java Sites CSS Zen Garden Evernote Hacker News Pragmatic Programmer
Read more

Oracle JDBC ReadTimeout QueryTimeout

If a query exceeds the oracle.jdbc.ReadTimeout without receiving any data, an exception is thrown and the connection is terminated by the Oracle driver on the client. Unfortunately the session will still be queued on the database and continue to wait for locks, hold any current locks, and complete any DML/PL*SQL procedures that are pending on the server-side of the orphaned connection. If an application, on a another connection, due to ReadTimeout exception, retries DML/PL*SQL  which requires locks, those queries will queue behind the initial DML/PL*SQL. This will increase the workload exacerbating the situation. On applications with retries, this can be observed by querying the v$session table  or gv$session on RAC and noting new sessions started periodically based on the ReadTimeout interval. The sessions may often have the same SQL_ID and/or SQL_HASH_VALUE. If stmt.setQueryTimeout(Seconds) is issued and the statement exceeds the timeout, it will atte...
Read more

Locks held on Oracle for hours after sessions abnormally terminated by node failure

If a session holds db locks and is abnormally terminated (no fin/ack), the locks will persist until the db session is closed, typically around 2 hours and 12 minutes with default network tcp_keepalive settings. Abnormally terminated does not include CTRL C or kill -9. The ojdbc6 driver apparently has a shutdown hook thread that closes the connections in graceful shutdowns. The OS apparently closes the connections when processes are killed. Abnormally terminated might include power failure, firewall failures, Out Of Memory, OS/kernel crash, network connection failure, JBoss or other server node failure, etc. This was easily reproduced by creating a  process that connected to the db and updated a record but did not commit. While the first process was waiting, a second process with a contending update was started which blocked on the first update. The first clients network cable was then disconnected. The second clients transaction waited for approximately 2 hours until the databa...
Read more