2011/4/29 Nicolas Lalevée <nicolas.lale...@hibnet.org>: > > Le 28 avr. 2011 à 21:39, Nicolas Lalevée a écrit : > >> >> Le 28 avr. 2011 à 00:39, Matt Benson a écrit : >> >>> 2011/4/27 Nicolas Lalevée <nicolas.lale...@hibnet.org>: >>>> I could only reproduce the apply-test failing locally (on a mac). >>>> The following command line got me more info about what's happening: >>>> ant -lib lib/optional/ant-antunit-1.1.jar antunit-report >>>> -Dantunit.testcase=taskdefs/exec/apply-test.xml -Dantunit.loglevel=info >>>> >>>> In the output I can see these lines: >>>> [au:antunit] error at LeadPipeInputStream.read(): Pipe broken >>>> [au:antunit] z after y after blah >>>> [au:antunit] error at LeadPipeInputStream.read(): Pipe broken >>>> [au:antunit] x after y after blah >>>> >>>> Not sure what to conclude from that since I'm not yet familiar with what >>>> LeadPipeInputStream does. At a first glance I would say that we could >>>> interpret that if the pipe is broken, then the "writing Thread is no >>>> longer alive", which would be basically be a nominal case and not an error >>>> one ? >>>> >>> >>> If it helps, LeadPipeInputStream (a poor pun) is intended to replace >>> the java.io.PipedInputStream to recover from "writing thread is no >>> longer alive" errors, because often there is data remaining to be read >>> when the writer has already sent all he had to send, then terminated. >> >> ok I see. Then I think it will make sense to handle the "Pipe broken" just >> like the "Write end dead". The read method in PipedInputStream start to >> check the thread status, and can fail with a IOE with "Write end dead" as a >> message the write thread is dead. If the write thread are still alive but no >> content is yet available, a loop begins to wait for content. Then if at some >> point there's still no content to read but the write thread has stopped, >> there is an IOE with "Pipe broken" as a message. So having either "Pipe >> broken" or "Write end dead" is just a matter of timing. >> >> I'll commit a fix. Tested locally the ant unit tests then works (tested >> several times). And I think it will fix the bug #48789 [1]. >> If gump shows us it now works I'll update the "what's new" and close #48789. >> If not I'll revert my commit. > > gump seems happier, bug closed as resolved.
Thanks for your attention to this, Nicolas. Matt > > One test still failing, I haven't looked at it: > > [au:antunit] Target: > test-redirector-input-output-inputencoding-outputencoding FAILED > [au:antunit] at line 552, column 24 > [au:antunit] Message: Assertion failed > [au:antunit] took 1.424 sec > > > Nicolas > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org > For additional commands, e-mail: dev-h...@ant.apache.org > > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org For additional commands, e-mail: dev-h...@ant.apache.org
