| Summary: | Hung forked JVM when reading from standard input | ||
|---|---|---|---|
| Product: | Ant | Reporter: | slackiz |
| Component: | Core tasks | Assignee: | Ant Notifications List <notifications> |
| Status: | NEW --- | ||
| Severity: | normal | CC: | flushdia |
| Priority: | P2 | ||
| Version: | 1.7.1 | ||
| Target Milestone: | --- | ||
| Hardware: | PC | ||
| OS: | Windows XP | ||
Could you please verify if this is solved in the currend "head" release? This could have to do with pr 44544. ping? Hi, Sorry for the late response. The problem is still not fixed in the source code that I downloaded from: svn co http://svn.apache.org/repos/asf/ant/core/trunk/ ant-core In this test, jvisualvm still freezed, when trying to connect to the application. Regards, Hendrik Hi, Just an update on this issue from an article that I found recently, which may be related since the described symptom is similar (though not the same). According to item G.2 in http://java.sun.com/j2se/1.4.2/docs/guide/rmi/faq.html#stdinput * Question: G.2 I have a single-threaded program that waits on standard input for a user command which will initiate an RMI call. However, my remote object cannot service this incoming remote call as the program appears to be blocked on standard input. What's the problem? * Answer: This is a known problem, not with RMI, but with the thread that reads standard input. The thread does not yield on the blocking read, but instead stays running, hardly letting the listener get any cycles. We have tried two workarounds that seem successful: set the main thread (the one reading standard input) to a lower priority, or yield while bytes are not available in the stream before actually reading it. Regards, Hendrik I am experiencing similar issues when using forked <java> followed by <input>. Let me explain the details.
Consider the following snippet of Ant XML code:
<target name="java-input">
<java classname="org.apache.tools.ant.launch.Launcher" fork="true">
<classpath>
<pathelement location="${ant.home}/lib/ant-launcher.jar" />
</classpath>
<arg value="-buildfile" />
<arg file="echo.xml" />
<arg value="echo" />
</java>
<input message="Do you want to proceed" validargs="y,n" defaultvalue="y" addproperty="proceed" />
<echo>User selected [${proceed}]</echo>
</target>
When running this target, <input> asks for input two times (not one) and accepts second entry as actual input.
Issue is not reproduced when running with fork="true" and spawn="true" OR with fork="false".
Issue can be fixed by adding inputstring="" to <java>, but what if <java> has to accept some input as well?
Shouldn't Ant workaround such situation?
@flushdia: this is a known and fixed bug you are reporting, see #49119 (In reply to comment #6) > @flushdia: this is a known and fixed bug you are reporting, see #49119 Thank you for pointing me to the right bug. Didn't find it during initial lookup. |
Hi, When launching a Java program from ant with "fork=true", the launched program seems to have *no* problem reading from the standard input (e.g. via System.in.read()), however this seems to stuff up the thread management of the launched program (i.e. the forked/child JVM) and possibly also crashes the child JVM. To reproduce this on a Windows XP (with Service Pack 3) using Sun JDK 6 update 10, I wrote a class with a main method that simply contains: try { System.out.println("X[Return] to quit"); while (System.in.read() != 'X') ; System.exit(0); // see shutdown hook for subsequent shutdown operations } catch (IOException e) { e.printStackTrace(); } When the program runs and blocks/waits for input from the user, if attached via JMX using JVisualVM (a tool that comes with Sun JDK 6 installation, for viewing the memory and thread state of a VM), JVisualVM will freeze and could not return any info about the JVM. The main thread of the JVM itself still works since System.in.read() still responds to user input, but the other threads of the program's JVM seem to have died and therefore the program/JVM cannot be connected via RMI, remote debugging, using -QUIT signal to get JVM thread dump, etc. The above is just a straightforward way to demostrate the problem, but in practice, without using JMX, the problem can also be reproduced using certain combinations of operations involving "complex" thread management, such as AWT event handling, RMI connection, etc. As such, it looks like that the problem is caused by a combination of the following factors: 1. Launching a program from ant using "fork=true" 2. The program blocks to receive input from user, e.g. System.in.read() 3. The program performs "complex" threading operation, such as exporting RMI remote objects, displaying a java.awt.Frame, connecting to the VM via JMX etc. The JVM hang problem is noticeable/reproducable: - On Windows XP (Service Pack 3, not sure about other service packs), but *no* problem on Linux and Windows Vista. - Using Sun JDK 1.4.2_14, 1.5.0_12, 1.6.0_10, and IBM J9 2.3 - Ant 1.7.0 and 1.7.1 I have no idea what could cause this problem, but I suspect that I/O redirection is not properly implemented in Windows XP, and thus crashing the JVM (e.g. interfering with the JVM's thread management). Thanks, Hendrik