{"action":"created","issue":{"url":"https://api.github.com/repos/netty/netty/issues/3193","labels_url":"https://api.github.com/repos/netty/netty/issues/3193/labels{/name}","comments_url":"https://api.github.com/repos/netty/netty/issues/3193/comments","events_url":"https://api.github.com/repos/netty/netty/issues/3193/events","html_url":"https://github.com/netty/netty/issues/3193","id":50642329,"number":3193,"title":"Handling TCP RST","user":{"login":"zcourts","id":692396,"avatar_url":"https://avatars.githubusercontent.com/u/692396?v=3","gravatar_id":"","url":"https://api.github.com/users/zcourts","html_url":"https://github.com/zcourts","followers_url":"https://api.github.com/users/zcourts/followers","following_url":"https://api.github.com/users/zcourts/following{/other_user}","gists_url":"https://api.github.com/users/zcourts/gists{/gist_id}","starred_url":"https://api.github.com/users/zcourts/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/zcourts/subscriptions","organizations_url":"https://api.github.com/users/zcourts/orgs","repos_url":"https://api.github.com/users/zcourts/repos","events_url":"https://api.github.com/users/zcourts/events{/privacy}","received_events_url":"https://api.github.com/users/zcourts/received_events","type":"User","site_admin":false},"labels":[{"url":"https://api.github.com/repos/netty/netty/labels/needs%20info","name":"needs info","color":"e6e6e6"}],"state":"open","locked":false,"assignee":null,"milestone":null,"comments":31,"created_at":"2014-12-02T11:53:45Z","updated_at":"2015-02-18T05:25:04Z","closed_at":null,"body":"I have a Netty HTTP server behind HAproxy.\r\nIn \r\n\r\n![TCP](http://upload.wikimedia.org/wikipedia/commons/a/a2/Tcp_state_diagram_fixed.svg)\r\n\r\n HAproxy sends an RST when a timeout is reached and closes the connection from its end, but the socket remains in Netty. \r\nI'm not sure of what TCP state the socket is in exactly, possibly \"Close Wait\" since this happens after \"Established\". The end result is too many files open after a while.\r\n\r\nlsof status says “can’t identify protocol”.  i.e.\r\n\r\n```bash\r\n\r\n$ lsof -Pnp 21709 | grep 34146\r\njava    21709 csr  638r     IPv6          465676654      0t0       TCP ip1:9012->ip2:34146 (ESTABLISHED)\r\n$ lsof -Pnp 21709 | grep 638r\r\njava    21709 csr  638r     sock                0,6      0t0 465676654 can't identify protocol\r\n\r\n```\r\nWhat is the expected behaviour when Netty receives an RST? How is an application suppose to handle it?\r\n\r\nPossibly related:\r\nhttps://github.com/netty/netty/issues/581\r\nhttps://github.com/netty/netty/issues/146"},"comment":{"url":"https://api.github.com/repos/netty/netty/issues/comments/74814552","html_url":"https://github.com/netty/netty/issues/3193#issuecomment-74814552","issue_url":"https://api.github.com/repos/netty/netty/issues/3193","id":74814552,"user":{"login":"jroper","id":105833,"avatar_url":"https://avatars.githubusercontent.com/u/105833?v=3","gravatar_id":"","url":"https://api.github.com/users/jroper","html_url":"https://github.com/jroper","followers_url":"https://api.github.com/users/jroper/followers","following_url":"https://api.github.com/users/jroper/following{/other_user}","gists_url":"https://api.github.com/users/jroper/gists{/gist_id}","starred_url":"https://api.github.com/users/jroper/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/jroper/subscriptions","organizations_url":"https://api.github.com/users/jroper/orgs","repos_url":"https://api.github.com/users/jroper/repos","events_url":"https://api.github.com/users/jroper/events{/privacy}","received_events_url":"https://api.github.com/users/jroper/received_events","type":"User","site_admin":false},"created_at":"2015-02-18T05:25:04Z","updated_at":"2015-02-18T05:25:04Z","body":"Ok, I've managed to get a packet capture, and I think (though am yet to confirm) that the issue I'm having is identical to @zcourts.  The SslHandler issue seems irrelevant, though is likely caused by the same thing.\r\n\r\nIn most cases, connections are closed using FIN, but in some cases, an RST is sent, and then nothing is done after that.  I believe these cases are the ones that are leaking connections in the CLOSE_WAIT state.  From my reading, you can close a connection using RST, but other reading I've done suggests you can't.  Wireshark highlights it as an error.\r\n\r\nSo anyway, here are the possible problems:\r\n\r\n* Netty is not handling RST closed connections properly.\r\n* The JDK is not handling RST closed connections properly.\r\n* Linux is not handling RST closed connections properly.\r\n\r\nNow, from reading [this](http://stackoverflow.com/questions/17990689/behaviour-of-select-on-remote-socket-closedby-killing-process), it seems that the difference between a RST and FIN is that -1 or 0 should be returned by a read.\r\n\r\nNow what does this mean for the JDK?  Well, a read should throw an exception if RST is received, and return -1 if FIN is received.  Does anything have to be done after that's received by either the JDK or the application?  Should the socket be closed?  I don't know, maybe you guys know more."}}