Use of Runtime.exec

I know that there are security concerns with making a call to the java.lang.Runtime's
exec method, but are there any performance concerns? When an exec call is made
by an object within the application server does the forking of a new process to
execute the command cause a process equivalent in size to the application server
to be generated? Our application server process is quite large, so this would
be an expensive operation.

The OS-level semantics of Runtime.exec are tied to JVM implementation (that's why
it doesn't work on most releases of the MacOS for example)...
Runtime.exec has a lot of not-so-intuitive handholding associated with it. For
example, did you know that on most flavors of Windows JVMs, you have to read out
of the STDOUT and STDERR streams, or the process you invoked will hang when their
buffer fills up? JavaWorld ran an article a while back with all the details on
this-- you can write a stream gobbler to suck up anything and send it to /dev/null
to avoid problems.
"Ash Beitz" <[email protected]> wrote:
>
I know that there are security concerns with making a call to the java.lang.Runtime's
exec method, but are there any performance concerns? When an exec call
is made
by an object within the application server does the forking of a new
process to
execute the command cause a process equivalent in size to the application
server
to be generated? Our application server process is quite large, so this
would
be an expensive operation.

Similar Messages

  • Using GUI Runtime.exec() another GUI, later come up, previous gone

    I try to run
    try {
         Runtime rt = Runtime.getRuntime();
         Process process = rt.exec("1.bat");
    InputStream stdin = process.getInputStream();
    InputStreamReader isr = new InputStreamReader(stdin);
    BufferedReader br = new BufferedReader(isr);
    String line = null;
    System.out.println("<OUTPUT>");
    while ( (line = br.readLine()) != null)
    System.out.println(line);
         int exitVal = process.exitValue();
         System.out.println("Process exitValue: " + exitVal);                         
    catch (Throwable e) {
         e.printStackTrace();
    1.bat file have
    ================
    del *.class
    set path=%path%;c:\j2sdk1.4.2\bin
    javac IDE.java
    java IDE
    I run the Runtime.exec code in Swing GUI, I will compile another
    Swing GUI (IDE.java) and run it. It work, but after when IDE GUI popup,
    all the button in the first calling GUI is gone, anyone have solution for it ? Thanks in advance.

    Your code is probably being executed in the event thread of the first application, thus blocking any and all screen updates.
    You should wrap the code in a separate Thread and start it in parallell.

  • I can not use the Runtime.exec() to open a file

    hi,
    i use java to open a pdf file like this:
    Runtime.getRuntime().exec("start c:/example.pdf");
    it works ok,but when i use java web start it do nothing,
    pls help me,why it can not work.
    thanks!

    I'm doing this with my app (getting access to the local filesystem and launch applications) and it works just fine.
    Things to do:
    1)
    Make sure your app is signed.
    (I used jarsigner to sign my jar file, comes with the j2se)
    2)
    Make sure in your .jnlp file that you are allowed to acces the filesystem, check your <security tags>
    <security>
    <all-permissions/>
    </security>
    3)
    From within the app try this to launch Acrobat Reader (win2000):
    Process pro = Runtime.getRuntime().exec("cmd.exe /C start acrord32");
    pro.waitFor();
    if (pro.exitValue() != 0)
    throw new IOException("AcrobatReader not installed");
    pro.waitFor() awaits your interaction with the filesystem, like closing an error popup dialog if os cannot find your file.
    When returning into your app, then check the exitValue. in windows, the exitvalue 1 is returned if the the file is missing. 0 if ok!
    I'm throwing an exception to handle further actions like opening a browser window with a given url to download the program.

  • How do I copy a file to a remote server using runtime exec - plz Help!

    Hi,
    I am trying to copy a file to a remote server using a runtime exec command as follows:
    Runtime.getRuntime().exec("scp "+getProperty(ListNewHandsetDetailsConstant.PROP_OUTPUT_PATH_JAR)+getProperty(ListNewHandsetDetailsConstant.PROP_OUTPUT_JAR_NAME)+".jar "+" "+getProperty(ListNewHandsetDetailsConstant.PROP_OUTPUT_PATH_TWO_USERNAME)+"@"+getProperty(ListNewHandsetDetailsConstant.PROP_OUTPUT_PATH_TWO_URL)+":"+getProperty(ListNewHandsetDetailsConstant.PROP_OUTPUT_PATH_TWO_JAR));
    Problem is this statement does not execute, as when I try it directly on command line, it requests for a password. Any suggestions on how I can get rid of that? I think I might have to configure my ssh_config file, but when I did some "Googling", I found the configuration settings of a ssh2_config file. I tried those (changing it to Host-based Authentication), but it didn't recognise them. Please help, this is so urgent!
    Regards,
    Simz

    Don't use Runtime.exec (or ProcessBuilder) for this. Check out JSch at JCraft (or some other Java SSH API.

  • Runtime.exec() - using cp and files with spaces on unix

    I'm using the Runtime.exec method to copy files in a unix environment. This works fine until there is a file where the name has spaces in it. I've read the article on the pitfalls of using runtime and how it breaks a string on white spaces and this is what is happening. I've also found another topic that was having the same problem, but they were using /usr/bin/dos2unix. I've tried putting quotes around the filename, but it still breaks on the first space. Any suggestions on how to get around this or another way of doing this would be greatly appreciated.
    An example of the os command string is:
    /usr/bin/cp /tmp/file with space.doc /docs
    Thanks!

    Hi!
    Well I dont have any Sun machine right here to try this but in windows It works great.
    Have you tried something like this ?
    import java.io.*;
    public class OSCopy {
        public static void main(String[] args) {
            try {
                String space = " ";
                String copycmd = "E:\\cp.cmd";
                String source = "E:\\File with space.txt";
                String destination = "E:\\tmp";
                String cmd = copycmd + space + "\"" + source + "\"" + space + destination;
                System.out.println("cmd: " + cmd);
                Runtime runtime = Runtime.getRuntime();
                Process copy = runtime.exec( cmd );
                BufferedReader reader = new BufferedReader( new InputStreamReader( copy.getInputStream()) );
                String line = null;
                while( (line = reader.readLine()) != null ) {
                    System.out.println( line );
            catch (Exception e) {
                e.printStackTrace();
    cp.cmd is a simple dos copy command
    copy %1 %2
    */good luck!

  • BufferedReader blocks when using Runtime.exec()

    I'm executing an external process in Linux (RH 8.0) using the Runtime.exec() method and then setup two threads to read the standard and error output of the process. Most of the time this works great but every now and then the readers block and the process never exit. I even tried seting up a timer task that will close the BufferedReader after 20 seconds but that's not enough to unblock the reader - the external process is a dummy shell script which for now just outputs a single line. Does anybody have any idea why that would happen? Any help would be appreciated!
    Cheers,
    /Francis
    P.S. Here's a snippet of the code:
    public class ProcessRunner {
      private Process _process = null;
      private StreamGobbler _errorGobbler = null;
      private StreamGobbler _outputGobbler = null;
      private String[] _commandArgs;
      public ProcessRunner(String[] args) {
        _commandArgs = args;
      public int runCommand()
        throws IOException {
        int exitCode = -1;
        _process = Runtime.getRuntime().exec(_commandArgs[0]);
        // start up stream gobblers (inspired from javaworld)
        _outputGobbler = new StreamGobbler(new BufferedReader(new InputStreamReader(_process.getInputStream())));
        _outputGobbler.setDaemon(true);
        _errorGobbler = new StreamGobbler(new BufferedReader(new InputStreamReader(_process.getErrorStream())));
        _errorGobbler.setDaemon(true);
        _outputGobbler.start();
        _errorGobbler.start();
        try {
          exitCode = _process.waitFor(); // *** THIS NEVER RETURNS ***
          if (_outputGobbler != null) {
            _outputGobbler.join();
          if (_errorGobbler != null) {
            _errorGobbler.join();
        } catch (InterruptedException exc) {
          //ok, continue
        return exitCode;
      class StreamGobbler extends Thread {
        BufferedReader reader;
        StreamGobbler(BufferedReader reader) {
          this.reader = reader;
        public void run() {
          try {
            final int buffersize = 256;
            byte[] bytes = new byte[buffersize];
            String line = null;
            while((line = reader.readLine()) != null) {    // ***THIS ALSO BLOCKS ***
              baos.write(line.getBytes(), 0, line.length());
          } catch (IOException ioe) {
            // Do something here
          } finally {
            reader.close();
            reader = null;

    I use this type of thing in my code using JDK1.3.1. Only difference is I don't use set up the readers in threads. I suspect you have a thread deadlock, but I can't see why. Do you have to have the i/o stream readers in the thread?

  • Runtime.exec() fails to run "javac" with "*.java" as arguments

    Hello,
    I am observing that Runtime.exec() consistently fails to execute "javac" when the Java files to be compiled are specified as "*.java". It fails with the following error:
    javac: file not found: /home/engine931/*.java
    Usage: javac <options> <source files>
    The same command used for Runtime.exec() runs fine from a the command shell. Is this is known problem with the Runtime class on UNIX, because it works fine on Windows.
    Any advise is appreciated.
    Thanks,
    Ranjit

    Your shell is expanding the command when you run javac from the shell. Try constructing your Runtime parameters so that your shell is executed, which then executes javac.
    The specific behavior is entirely dependent on the command interpreter that's used.

  • Executing a runtime.exec statement from an ejb

    Hi all,
    relativly new to j2ee. I need to use the runtime.exec command to uncompress a set of files from an ejb.
    So far, ive tried that and even the most basic commands like
    /usr/bin/ll *
    and i don't get any response back other than: exit value = 2
    when executing:
    Runtime runtime = Runtime.getRuntime();
    // Process proc = runtime.exec("/usr/bin/uncompress "+this.localFileStore+"*.Z");
    Process proc = runtime.exec("/usr/bin/ll * ");
    // put a BufferedReader on the ls output
    InputStream inputstream = proc.getInputStream();
    InputStreamReader inputstreamreader = new InputStreamReader(inputstream);
    BufferedReader bufferedreader = new BufferedReader(inputstreamreader);
    // read the ls output
    String line;
    while ((line = bufferedreader.readLine()) != null) {
    System.out.println(line);
    // check for ls failure
    try {
    if (proc.waitFor() != 0) {
    System.err.println("exit value = " + proc.exitValue());
    catch (InterruptedException e) {
    System.err.println(e);
    No output from the buffered reader. Any one have any ideas as to why i cannot execute any runtime commands? This is also related to the thread i created where i'm looking for a java library for uncompressing a unix compressed file (unix compress = *.z and not zip or gz files). I think my only two options are to either use the runtime to uncompress these files or.. use some java library to uncompress these files. Let me know if anyone can offer any hints/helpfull comments/libs
    Thanks a bunch

    I might be wrong on this one, but I believe using Runtime.exec() would generally be frowned upon when invoked from an EJB. The reason? EJB implies a remote call. Can you guarantee that a given native process or service will be available on all possible remote nodes that the EJB might be deployed on? Maybe. Can it actually be achieved? Yes. Is it in the spirit of EJB? Probably not.
    - Saish

  • Java.lang.Runtime.exec()

    When using the exec method I cannot get it to run the specified application when I try to use the Runtime.execString[] cmdArray)
    The application I am running is windump, it runs ok when I specify it in the Runtime.exec(String cmd) method.
    I need to use the Runtime.exec(String[] cmdArray) option as I need to specify parameters as part of my project. To be exact I need to tell it to output to a text file.
    I can do this when running windump from the command prompt, thus cannot understand whty it wont work when I specify the same option from Runtime.exec(..)
    Any ideas how to overcome this?
    thanks Conor

    This works for me on WindowsNT:
    try {
         Runtime.getRuntime().exec("cmd.exe /c dir>dirtest.txt");
    catch (Exception e) {}
    [/code}
    Mark

  • Runtime.exec() for openning a browser

    hey guys!!
    I could open a browser using a runtime.exec(). once i have opened it can i use the process.getOuputStream() method to read what is there in the browser.
    How do i communicate with the browser?
    -karthek

    No, getOutputStream will read only what the program writes to standard output. Typically, GUI programs don't even use standard output. The only way you can communicate with processes started by Runtime.exec that I know of is with the Process class.

  • Runtime.exec() under a specific user account ???

    Hi there,
    I cann't figure out how to run a script on Unix under a specific user account using the Runtime.exec(). Currently whoever run the java program, the script is ran under that user account.
    The code is like:
    public class javarun {
    public static void main(String[] arg) {
    String str = "myunixscript";
    // check the arg[1] to decide the appropriate environment.
    Runtime r = Runtime.getRuntime();
    try {
    Process pr = r.exec(str);
    pr.waitFor();
    int exitstatus = pr.exitValue();
    } catch (...) {...}
    We have two user accounts: unixusr1 and unixusr2. Now I need to have unixusr1 run the java program ( ie. unixusr1$ java javarun), while the "myunixscript" be executed under unixusr2. One further step is to the unix account name as a parameter so the unixscript could be run under different account.
    Any help will be highly appreciated. Thanks.
    Edward.

    I'm not sure if I have a solution, but here are some questions:
    a) have you tried writing additional input to the OutputStream of the process? Although I have not tried it, I would imagine that Process.getOutputStream() exists for commands that require the invoking resource to send additional input to the process- like an su command that requires a password check.
    b) can you just write a shell script that takes the needed information as an argument. That is, write a shell script that takes the username and password as an argument and then you can use Runtime like,
    Runtime.exec("myScript", new String[] { "hisId", "hisPasswd" });Obviously, you would need to think through the security concerns of such a script, but, if it complies with the security structure of your environment, it might allow you to avoid the problem by using the shell script to invoke the destination command with the proper UID and password, rather then using the JVM to invoke it. Basically, the script becomes a proxy for the JVM to invoke that command.

  • Runtime exec IOException issues

    Hello,
    I have spent two 10 hours days on this problem with countless search permutations and peering into everything from kernel source to java source. Unfortunately, I am not coming up with useful results.
    Overview:
    I have a very large java application (Apache solr) running on a server with 12GB memory. Without going into too much detail, this application at a point will use a Runtime exec call to fire off a bash shell script. Over time, however, I end up with an IOException "Cannot allocate memory." (More info and stack trace below.)
    That application aside I have been able to reproduce this by varying the -Xms and -Xmx jvm parameters with confusing results using the simple program below:
    //Use with various -Xms and -Xmx arguments to produce
    //IOException on call to Runtime.exec()
    import java.io.*;
    public class DoRuntime {
       public static void main(String args[]) throws IOException {
          Runtime runtime = Runtime.getRuntime();
          long total = runtime.totalMemory();
          long max = runtime.maxMemory();
          long free = runtime.freeMemory();
          System.out.println("total: " + total);
          System.out.println("max: " + max);
          System.out.println("free: " + free);
          Process process = runtime.exec("/bin/ls");
          InputStream is = process.getInputStream();
          InputStreamReader isr = new InputStreamReader(is);
          BufferedReader br = new BufferedReader(isr);
          String line;
          while ((line = br.readLine()) != null) {
             System.out.println(line);
    }Here are some sample runs:
    RUN1
    rwoodrum@util1wad:~/tmp$ java DoRuntime
    total: 188743680
    max: 954466304
    free: 187759312
    DoRuntime.class
    DoRuntime.java
    rwoodrum@util1wad:~/tmp$
    RUN2
    rwoodrum@util1wad:~/tmp$ java -Xms10g -Xmx10g DoRuntime
    total: 10290069504
    max: 10290069504
    free: 10236381080
    Exception in thread "main" java.io.IOException: java.io.IOException: Cannot allocate memory
            at java.lang.UNIXProcess.<init>(UNIXProcess.java:148)
            at java.lang.ProcessImpl.start(ProcessImpl.java:65)
            at java.lang.ProcessBuilder.start(ProcessBuilder.java:451)
            at java.lang.Runtime.exec(Runtime.java:591)
            at java.lang.Runtime.exec(Runtime.java:429)
            at java.lang.Runtime.exec(Runtime.java:326)
            at DoRuntime.main(DoRuntime.java:14)
    rwoodrum@util1wad:~/tmp$
    RUN3
    rwoodrum@util1wad:~/tmp$ java -Xms10g -Xmx11g DoRuntime
    total: 10290069504
    max: 10498867200
    free: 10236381080
    DoRuntime.class
    DoRuntime.java
    rwoodrum@util1wad:~/tmp$-----
    (FWIW, I get the same results replacing /bin/ls with something as lightweight as /bin/true.)
    As can be seen in the above output of RUN2, I have set a fixed heap size of 10GB. The jvm seems content with that heap size, but when it goes to exec the child process it becomes rather unhappy. From this I would perhaps conclude that ultimately inside the call to forkAndExec (libjava.so) the call to fork() failed with an ENOMEM. (As a side note, an strace on the process doesn't actually ever show a fork, only a call to clone - which utilizes a fork eventually - more on clone below.)
    The results of RUN3, however, seem to imply that the problem is within the jvm itself. In RUN3, I set the initial heap allocation to 10GB, as in RUN2, but I set the maximum at 11GB. One would think (or at least I would) that if the fork in RUN2 failed that it would certainly fail in the case of RUN3. It doesn't.
    The manpage of clone indicates that the child process will "share parts of its execution context with the calling process". Indeed, if I'm reading it correctly, it indicates that the child process stack (among other things) is housed in the parent process address space.
    Could it be that by setting this very large, fixed heap size as in RUN2, there is no room for the jvm to "maneuver" and properly handle the effort of the Runtime.exec? The fact that RUN3 is successful is what has made me think something like this, but I am by far an expert on how the jvm would handle that sort of thing.
    In our production setup of this application, I adjusted the Xmx setting to be something larger than the Xms setting. This worked for a period of time, but eventually produced the same results. I suspect over time the heap simply increased toward the max and again the jvm couldn't do its thing when it came time to RunTime.exec. The fact that this happens on the trivial Runtime.exec program would seem to rule out a memory leak of the production application.
    Ultimately something fishy is going on with memory, but with seemingly contradictory results, I am at a loss of where the problem lies.
    If I have omittied any potentially relevant information, please let me know. Any thoughts are greatly appreciated.
    Some basic system information:
    rwoodrum@util1wad:~/tmp$ free
                 total       used       free     shared    buffers     cached
    Mem:      12304936   12200376     104560          0     337276    7082508
    -/+ buffers/cache:    4780592    7524344
    Swap:      2097144         32    2097112
    rwoodrum@util1wad:~/tmp$ uname -a
    Linux util1wad 2.6.18-4-amd64 #1 SMP Mon Mar 26 11:36:53 CEST 2007 x86_64 GNU/Linux
    rwoodrum@util1wad:~/tmp$ java -version
    java version "1.5.0_10"
    Java(TM) 2 Runtime Environment, Standard Edition (build 1.5.0_10-b03)
    Java HotSpot(TM) 64-Bit Server VM (build 1.5.0_10-b03, mixed mode)-ryan woodrum

    I've continued to investigate this with my discoveries below. I've found some more interesting nuances, but am still not satisfied with the explanation of what is going on here. For time reasons, I've capitulated to a somewhat lame workaround.
    The test run in the 1.6.0 jvm environment is somewhat revealing in that it confirms that the eventual call to fork (I'm kind of guessing it's the fork call here) is returning an ENOMEM. The 1.5.0 jvm was not returning the actual errno from the call in the JNI code. Checking out $linux_src/include/asm-generic/errno-base.h indeed enumerates ENOMEM to 12.
    When I saw this, I started looking at the memory commit inside of /proc/meminfo to see what was going on when I would launch the jvm with the varying Xmx and Xms parameters. Somewhat unsurprisingly at this point, when I would run with large a large heap, the Committed_AS would skyrocket by a proportion roughly equal to the fixed heap size. (See here http://lwn.net/Articles/28345/ for an definition of Committed_AS and other /proc/meminfo fields.)
    With the above information in hand, I wanted to confirm without a doubt that the kernel was the thorn in my side. So on a test system I started to play around with the vm_overcommit feature - see $linux_src/Documentation/vm/overcommit-accounting for definitions of modes 0,1, and 2). Sure enough, toying with these modes I was able to alter the behavior of launching the jvm. I switched from the default heuristic mode (0) to an "always overcommit" mode and it would launch and sucessfully fork and exec every time. No surprise there.
    What IS surprising, however, is that if, under the default heuristic mode, I specify the jvm parameters differently it will sucessfully run and fork and exec the subprocess. It seems odd to me that at the OS level, specifying `java -Xms4g -Xmx4g` will cause the subprocess fork to fail but specifying `java -Xms4g -Xmx5g` will NOT cause the fork to fail. Running with the latter parameters shows the exact same Committed_AS spike. This all begs the question(s): What's the difference? With a min heap size set to 4g (or whatever) on the both jvm runs, how does a jvm parameter (especially one that allows MORE growth of the heap) impact this call to fork? One variable in the picture at this point that I'm unsure of is the strace call to clone(). I don't know what this could be doing to make things behave differently.
    So as I noted, above, I have a relatively lame workaround. Blindly add more swap to increase the CommittedLimit inside the kernel. It'll never get used, it's a waste of space, and, perhaps most importantly, on principal it just rubs me the wrong way.
    -ryan woodrum

  • Runtime.exec() does not work?

    I'm trying to invoke a C++ executable from java using the Runtime.exec() method. The C++ application accepts a filename as a command line argument & opens the file. This C++ app is unicode enabled i.e. it can accept UTF-16 (wide char) parameters. Howevere, when i invoke this application using Java's Runtime.exec() and specify a japanese file name as an argument, the japanese characters get converted to '?' characters by the time they are received in the C++ application. I'm running this application on Windows 2K, default i.e. English version.
    Looking at the source code of Runtime class, it seems that the exec()
    function makes use of a native helper function - execInternal(). Does
    this function support the entire unicode range?
    Is there any way we can avoid the conversion of japanese characters to '?' characters? Also, is there any other alternative for invoking an external application with Unicode (Say, japanese) arguments?
    Please reply ASAP.
    Thanks!

    >
    I'm trying to invoke a C++ executable from java using
    the Runtime.exec() method. The C++ application accepts
    a filename as a command line argument & opens the
    file. This C++ app is unicode enabled i.e. it can
    accept UTF-16 (wide char) parameters. Howevere, when i
    invoke this application using Java's Runtime.exec()
    and specify a japanese file name as an argument, the
    japanese characters get converted to '?' characters by
    the time they are received in the C++ application. I'm
    running this application on Windows 2K, default i.e.
    English version.
    Looking at the source code of Runtime class, it seems
    that the exec()
    function makes use of a native helper function -
    execInternal(). Does
    this function support the entire unicode range?I don't know because I've never tested this case specifically.
    You didn't show your code though. How are you reading in the String? You mentioned that you passed a Japanese character String as a filename argument. I also read that you are running on an English Win2K platform. How did you read that argument in? It may just be that you read the argument in your default encoding(English) and you needed to specify an alternate one.

  • Runtime.exec does not execute my program, but executes "ls"

    I am trying to run an exe from a Java program.
    The program that I want to run is an output of a gcc -o ICDDATA ICDdata.c
    Now when I use the Runtime.exec() and execute "ls", "cat" it is working fine without any errors.
    But when i try to give the file(ICDDATA) that was created with the gcc, it generates an error code of "11" or "10" and exits the process.
    Could anyone please let me know the reason why this is happenig and suggest and appropiate solution for this.

    When I give ICDDATA at the prompt, it is executing perfectly fine.
    But only when it is run inside the Java program its giving the error code 10.
    Here is the source code:
    ======================================
    public class InvokeInterface {
         This method takes two parameters and accordingly invokes one of the
         interface (ICD / Value).
         @Input : String, String
         @Return : void
         static void executeInterface(String processName, String debugOption)
         throws java.io.IOException     {
              String commandToExecute=". / ";
                   // The command that has to be passed to the Shell.
              if(processName.equals("ICD"))
                   commandToExecute="ICDDataRefresh";
              if(processName.equals("VALUE"))
                   commandToExecute="ValueDataRefersh";
              commandToExecute += " "+debugOption;
              System.out.println("..."+commandToExecute);
              Runtime runtime = Runtime.getRuntime();
              Process proc = runtime.exec(commandToExecute);
                   try {
                        if (proc.waitFor() != 0) {
                        System.err.println("exit value = " +
                        proc.exitValue());
              catch (InterruptedException e) {
                   System.err.println(e);
    ==========
    Thanks in Advance
    Ram

  • Runtime.exec() causes app to hang

    Hello all, I'm having an issue with the Runtime.exec() and I'm hoping someone in the forum can shed some light on it for me.
    My application currently includes the capability for my end users to run a variety of reports, all of which are written in SQR (BRIO reporting language). Since my application is in Java ( and all the reports were written for a previous application), I use the Runtime.exec() call to launch the SQR viewer application. The problem I'm having is this: When I run the code below in my development environment (using a front end framework from Oracle (JDeveloper)), everything works fine. When I deploy my application to a jar file, the application runs fine until the code below is called. At this point the application hangs terribly and my CPU usage is maxed out by my app. The process for the report is created but is unable to garner the necessary resources to run because my application is using them all. If I kill my application, the report process then runs as expected.
    Why would the same code run fine in development but not when deployed to a jar file?
    The following is the code in question:
        try {
          Runtime rt = Runtime.getRuntime();
          Process proc = rt.exec(sDrive + "\\SQR6\\SQRW " + sDrive + "\\SQR6\\REPORTS\\" + repName + ".SQT " + sConn + " -RT -FC:\\SPL\\ -C -ZIV");
          InputStream stderr = proc.getErrorStream();
          InputStreamReader isr = new InputStreamReader(stderr);
          BufferedReader br = new BufferedReader(isr);
          String line = null;
          while ( (line = br.readLine()) != null)
            System.out.println(line);
          int exitVal = proc.waitFor();
        catch (Throwable ie)
          ie.printStackTrace();
        }    All thoughts and suggestions are welcomed.
    Thanx in advance,
    eribs4e

    So you either tried adding a reader for stdout, or you're sure that nothing is produced on stdout? And you're sure it's not expecting anything on stdin?
    You say your app runs fine up to that code, and then eats all the CPU right? Sounds like a spin lock. One possibility is that it's something like this: br = bufferedReaderForStdOut;
    while ( (line = br.readLine()) != null)
            System.out.println(line);
    while ((line = br.readLine() == null); Not that I expect that you have precisely that in your code, but I suspect the problem may actually be a spin-lock that precedes the code you've posted. I don't see anything obviously wrong with what you have, so if there's a problem in your code, it's probably in what you haven't shown.

Maybe you are looking for