http://dev.clojure.org/jira This file is an XML representation of an issue en-us 4.4 649 25-07-2011 http://dev.clojure.org/jira/browse/NREPL-30 tools.nrepl <p>See <a href="https://github.com/trptcolin/reply/issues/84#issuecomment-8481753">https://github.com/trptcolin/reply/issues/84#issuecomment-8481753</a> and maybe <a href="http://code.google.com/p/counterclockwise/issues/detail?id=405">http://code.google.com/p/counterclockwise/issues/detail?id=405</a></p> NREPL-30

Investigate hangs when server goes away

Task Major Closed Completed Chas Emerick Chas Emerick Fri, 14 Sep 2012 07:39:07 -0500 Mon, 8 Oct 2012 12:42:34 -0500 Mon, 8 Oct 2012 12:42:34 -0500 0.2.0-beta9 0.2.0-beta10 0.2.0-beta10 0 0 <p>If it helps, I did observe in some testing that after the server side of the socket goes down, writing to and flushing the client socket's output stream <b>twice</b> would bubble up a client exception. That seems a little keepalive-ish, but I'm not sure whether that sort of thing would do other transports any good.</p> <p>A fix for this is on master now, with commit <a href="https://github.com/clojure/tools.nrepl/commit/8a5dad2045434fcc06f2878de55f7dcdefa01a1b">8a5dad2045434fcc06f2878de55f7dcdefa01a1b</a>. There were a number of issues in the implementation of <tt>FnTransport</tt> that were preventing exceptions from bubbling up as they should have been.</p> <p>No APIs were harmed in the course of implementing a fix. Also, no keepalive mechanism was required (which makes me slightly suspicious that the issue has actually been fixed, but we'll see). (Not TCP keepalive; that's irrelevant to the issue, and wouldn't help even if it were reliably standard/present.)</p> <p>New tests added, and manual verification against nREPL servers running in different processes looks good too. I'll put out an <tt>0.2.0-beta10</tt> shortly so that people can start banging on this to see if it resolves issues in downstream projects/tools.</p> <p>Note that I also found that it <b>sometimes</b> requires two sends (messages here, not writes to a socket) to provoke an error when writing to a transport that had been connected to a server that was closed or otherwise went away. Maybe it's a buffering issue? I don't have a good theory. Check out e.g. <tt>nrepl-test/transports-fail-on-disconnects</tt> if you want to play around with it.</p> <p>Note that the bencode transport should throw a <tt>java.net.SocketException</tt> when its connection is lost.</p> <p>Good reports received from downstream projects on the fix for this. Calling it good.</p> Global Rank