<!-- 
RSS generated by JIRA (4.4#649-r158309) at Fri May 24 16:11:58 CDT 2013

It is possible to restrict the fields that are returned in this document by specifying the 'field' parameter in your request.
For example, to request only the issue key and summary add field=key&field=summary to the URL of your request.
For example:
http://dev.clojure.org/jira/si/jira.issueviews:issue-xml/NREPL-12/NREPL-12.xml?field=key&field=summary
-->
<rss version="0.92" >
<channel>
    <title>Clojure JIRA</title>
    <link>http://dev.clojure.org/jira</link>
    <description>This file is an XML representation of an issue</description>
    <language>en-us</language>    <build-info>
        <version>4.4</version>
        <build-number>649</build-number>
        <build-date>25-07-2011</build-date>
    </build-info>

<item>
            <title>[NREPL-12] Intermittent test failures for stdin</title>
                <link>http://dev.clojure.org/jira/browse/NREPL-12</link>
                <project id="10022" key="NREPL">tools.nrepl</project>
                        <description>&lt;p&gt;Failures like these are happening sometimes in the test suite, mainly around stdin:&lt;/p&gt;

&lt;p&gt;FAIL in (request-multiple-read-objects-&lt;b&gt;in&lt;/b&gt;) (nrepl_test.clj:211)&lt;br/&gt;
expected: (= (quote (:ohai)) (response-values (for &lt;span class=&quot;error&quot;&gt;&amp;#91;resp (repl-eval session &amp;quot;(read)&amp;quot;)&amp;#93;&lt;/span&gt; (do (when (-&amp;gt; resp :status set (contains? &quot;need-input&quot;)) (session {:op :stdin, :stdin &quot;:ohai :kthxbai\n&quot;})) resp))))&lt;br/&gt;
  actual: (not (= (:ohai) nil))&lt;/p&gt;

&lt;p&gt;FAIL in (request-multiple-read-objects-&lt;b&gt;in&lt;/b&gt;) (nrepl_test.clj:217)&lt;br/&gt;
expected: (= &lt;span class=&quot;error&quot;&gt;&amp;#91;&amp;quot; :kthxbai&amp;quot;&amp;#93;&lt;/span&gt; (repl-values session &quot;(read-line)&quot;))&lt;br/&gt;
  actual: (not (= &lt;span class=&quot;error&quot;&gt;&amp;#91;&amp;quot; :kthxbai&amp;quot;&amp;#93;&lt;/span&gt; nil))&lt;/p&gt;

&lt;p&gt;I&apos;ve done a ton of debugging and thinking about this, and haven&apos;t gotten far. A few theories I had that seemed decent at the time, but ultimately haven&apos;t gotten rid of these occasional failures:&lt;/p&gt;

&lt;ul class=&quot;alternate&quot; type=&quot;square&quot;&gt;
	&lt;li&gt;in middleware.session/add-stdin, flush the :stdin-writer after writing to it on :stdin messages (see &lt;a href=&quot;http://stackoverflow.com/questions/2843555/better-alternative-for-pipedreader-pipedwriter&quot;&gt;http://stackoverflow.com/questions/2843555/better-alternative-for-pipedreader-pipedwriter&lt;/a&gt;)&lt;/li&gt;
	&lt;li&gt;in server/handler, when a message is received on the transport, farm the handling out to a future (this is half-baked &amp;amp; caused additional intermittent failures)&lt;/li&gt;
&lt;/ul&gt;


&lt;p&gt;The debugging I&apos;ve been doing (print statements galore) suggests that when this problem happens, the client does send back the proper :stdin, but it doesn&apos;t get picked up by the add-stdin handler in time to write to the :stdin-writer and avoid the expiring timeout.&lt;/p&gt;

&lt;p&gt;I&apos;m pretty much stumped at this point, unfortunately.&lt;/p&gt;</description>
                <environment></environment>
            <key id="15248">NREPL-12</key>
            <summary>Intermittent test failures for stdin</summary>
                <type id="1" iconUrl="http://dev.clojure.org/jira/images/icons/bug.gif">Defect</type>
                                <priority id="2" iconUrl="http://dev.clojure.org/jira/images/icons/priority_critical.gif">Critical</priority>
                    <status id="6" iconUrl="http://dev.clojure.org/jira/images/icons/status_closed.gif">Closed</status>
                    <resolution id="1">Completed</resolution>
                                <assignee username="cemerick">Chas Emerick</assignee>
                                <reporter username="trptcolin">Colin Jones</reporter>
                        <labels>
                    </labels>
                <created>Sun, 26 Feb 2012 13:04:29 -0600</created>
                <updated>Sun, 10 Jun 2012 16:40:48 -0500</updated>
                    <resolved>Sun, 10 Jun 2012 16:40:48 -0500</resolved>
                                            <fixVersion>0.2.0</fixVersion>
                                        <due></due>
                    <votes>0</votes>
                        <watches>0</watches>
                        <comments>
                    <comment id="28052" author="cemerick" created="Thu, 29 Mar 2012 16:18:56 -0500"  >&lt;p&gt;This is becoming a serious problem; the build fails half the time on build.clojure.org, making it incredibly frustrating to perform releases, etc.&lt;/p&gt;

&lt;p&gt;Any new ideas / evaluation of this is most welcome.&lt;/p&gt;</comment>
                    <comment id="28153" author="trptcolin" created="Sun, 15 Apr 2012 22:24:08 -0500"  >&lt;p&gt;My current vague suspicion is that it&apos;s a CPU contention thing between the server and client.  &lt;/p&gt;

&lt;p&gt;It&apos;s kind of hard for me to reason about the execution of the response-values lazy seq, and where the blocking actually happens. And of course adding logging changes the behavior sometimes. I wouldn&apos;t be opposed to adding sleeps in there, but I expect those kinds of things would still be flaky later, on build machines in particular :/&lt;/p&gt;

&lt;p&gt;Incidentally, bumping the client timeout up to Long.MAX_VALUE helps a bit the stdin failures, but doesn&apos;t solve them. It does create new ones: session-lifecycle, unknown-op, and read-timeout block forever trying to reduce across the whole seq in combine-responses. It was a bit surprising to me to see that reduce in the response-values pipeline, and I pursued that at one point as well, but it hasn&apos;t gotten me anywhere. Decreasing the timeout helps to reproduce the failures.&lt;/p&gt;

&lt;p&gt;I got this thread dump from a blocking-forever stdin test (run via `lein test clojure.tools.nrepl-test`): &lt;a href=&quot;https://refheap.com/paste/2141&quot;&gt;https://refheap.com/paste/2141&lt;/a&gt;. &lt;/p&gt;</comment>
                    <comment id="28688" author="trptcolin" created="Sun, 3 Jun 2012 05:07:49 -0500"  >&lt;p&gt;With this patch, I was able to run clojure.tools.nrepl-test 100 times successfully. Previous attempts would generally only get as far as 15 or so before failing for one reason or another.&lt;/p&gt;

&lt;p&gt;It also gets rid of a race condition with my skip-if-eol stuff that was addressing multiple input reads. Lastly, it avoids the need for the 10-second timeout, so the tests are faster now as well.&lt;/p&gt;</comment>
                    <comment id="28766" author="cemerick" created="Sat, 9 Jun 2012 10:57:22 -0500"  >&lt;p&gt;I&apos;m psyched that you may have found the solution to these problems.  I&apos;ve applied the patch locally, and it tests well.  I want to eyeball it for a minute (probably tomorrow) before moving on.&lt;/p&gt;</comment>
                    <comment id="28769" author="cemerick" created="Sun, 10 Jun 2012 16:40:48 -0500"  >&lt;p&gt;Pushed, will be in the next beta release.  Thanks so much!&lt;/p&gt;</comment>
                </comments>
                    <attachments>
                    <attachment id="11286" name="0001-Improve-timing-issues-in-tests.patch" size="3850" author="trptcolin" created="Sun, 3 Jun 2012 05:07:49 -0500" />
                </attachments>
            <subtasks>
        </subtasks>
                <customfields>
                                                                                            <customfield id="customfield_10010" key="com.pyxis.greenhopper.jira:gh-global-rank">
                <customfieldname>Global Rank</customfieldname>
                <customfieldvalues>
                    
                </customfieldvalues>
            </customfield>
                                                                                                            </customfields>
    </item>
</channel>
</rss>