| exec task hangs with j2sdk 1.4.1 / linux? | exec task hangs with j2sdk 1.4.1 / linux? 2003-03-15 - By Mike Hardy
Not the *best* answer technically since 1.4.0 has garbage collector bugs
that segfault the VM sometimes, but I'm in the position I can revert now
and wait for the future so I guess its okay.
Thank you very much for the pointer, I skimmed through the bug parade but
didn't see it.
Cheers-
-Mike
On Sat, 15 Mar 2003, Eric Weidner wrote:
> Mike,
>
> This is a Java 1.4.1 bug. It has been fixed in 1.4.2. We ran into this
> because we use a lot of execs in our product.
>
> See http://developer.java.sun.com/developer/bugParade/bugs/4750978.html.
>
> The workaround is to revert to 1.4.0 for anything that needs execs or
> wait for 1.4.2 which should have a beta out soon.
>
> Eric
> Out-of-the-Box
> http://www.ejbsolutions.com
>
>
> Mike Hardy wrote:
>
> >The exec task doesn't take a fork argument - I'm calling
> >Tomcat's startup.sh, not the Tomcat class directly via the ant java task.
> >
> >I did try vmlauncher="false" and "true", and I also tried
> >output="/dev/null" to see if I could get it to ignore the streams, but
> >neither helped.
> >
> >I'm still hunting around for something. Its definitely the sub-processes
> >output streams that are breaking an assumption somewhere. In the line of
> >code referenced in the thread dump from CVS for ant 1.5.2 its sitting
> >there polling the stream for input. It never comes and the stream doesn't
> >close though, so it hangs forever
> >
> >-Mike
> >
> >On Fri, 14 Mar 2003, Martin wrote:
> >
> >
> >
> >>Mike-
> >>Did you try it with fork = "true"
> >>-Martin
> >>
> >>----- Original Message -----
> >>From: "Mike Hardy" <mhardy@(protected)>
> >>To: <user@(protected)>
> >>Sent: Friday, March 14, 2003 6:40 PM
> >>Subject: exec task hangs with j2sdk 1.4.1 / linux?
> >>
> >>
> >>
> >>
> >>>Hello everyone -
> >>>
> >>>First, I'll apologize if this has already been hashed out, I searched
> >>>everywhere I could (bug db, mailing list archive, google) and didn't find
> >>>it, but I might have just missed it.
> >>>
> >>>Here's my problem, since upgrading from Sun's j2sdk 1.4.0 on linux (redhat
> >>>7.2 patched up a lot) to Sun's j2sdk 1.4.1, ant is no longer able to
> >>>successfully fire off an exec task that calls Tomcat's startup.sh. I have
> >>>tried ant 1.5.2 and the problem still occurs for me
> >>>
> >>>It used to work just fine, I would see the catalina.sh output, then the
> >>>shell scripts would finish as tomcat went into daemon mode, the task would
> >>>return, and ant would exit. Now it just hangs there, making it a manual
> >>>process.
> >>>
> >>>With ordinary shell scripts or other binaries, this works (I checked
> >>>/bin/echo, and writing a shell script that echo'd things). So I'm focusing
> >>>in on the JVM.
> >>>
> >>>Is there a known problem with 1.4.1 leaving the stdin, stdout or stderr
> >>>file handles open?
> >>>
> >>>It seems that's what's ant is waiting on given this info:
> >>>
> >>>"Thread-3" daemon prio=1 tid=0x0x832cdf8 nid=0x6610 runnable
> >>>[be5ff000..be5ff860]
> >>> at java.io.FileInputStream.readBytes(Native Method)
> >>> at java.io.FileInputStream.read(FileInputStream.java:174)
> >>> at
> >>>org.apache.tools.ant.taskdefs.StreamPumper.run(StreamPumper.java:105)
> >>> at java.lang.Thread.run(Thread.java:536)
> >>>
> >>>"Thread-2" daemon prio=1 tid=0x0x82dc510 nid=0x660e runnable
> >>>[be7ff000..be7ff860]
> >>> at java.io.FileInputStream.readBytes(Native Method)
> >>> at java.io.FileInputStream.read(FileInputStream.java:191)
> >>> at java.io.BufferedInputStream.fill(BufferedInputStream.java:183)
> >>> at java.io.BufferedInputStream.read1(BufferedInputStream.java:222)
> >>> at java.io.BufferedInputStream.read(BufferedInputStream.java:277)
> >>> - locked <0x4424f670> (a java.io.BufferedInputStream)
> >>> at java.io.FilterInputStream.read(FilterInputStream.java:90)
> >>> at
> >>>org.apache.tools.ant.taskdefs.StreamPumper.run(StreamPumper.java:105)
> >>> at java.lang.Thread.run(Thread.java:536)
> >>>
> >>>
> >>>
> >>>If anyone has any information on how to work around this, or avoid it
> >>>completely, I'd really appreciate it.
> >>>
> >>>Thanks in advance for any help-
> >>>-Mike
> >>>
> >>>
> >>>---------------------------------------------------------------------
> >>>To unsubscribe, e-mail: user-unsubscribe@(protected)
> >>>For additional commands, e-mail: user-help@(protected)
> >>>
> >>>
> >>>
> >>>
> >>---------------------------------------------------------------------
> >>To unsubscribe, e-mail: user-unsubscribe@(protected)
> >>For additional commands, e-mail: user-help@(protected)
> >>
> >>
> >>
> >
> >
> >---------------------------------------------------------------------
> >To unsubscribe, e-mail: user-unsubscribe@(protected)
> >For additional commands, e-mail: user-help@(protected)
> >
> >
> >
> >
> >
>
>
|
|
 |
