Uploaded image for project: 'Groovy'
  1. Groovy
  2. GROOVY-2305

Process .getText() GDK method blocks on some operating systems.



    • Improvement
    • Status: Closed
    • Major
    • Resolution: Fixed
    • 1.5.5
    • 1.6-rc-1
    • groovy-jdk
    • None
    • Windows, perhaps others. See JavaDoc for java.lang.Process.


      Pulled from the USER email group on 11/14/2007:

      > i am executing maven reports inside a certain folder with

      new File('.').eachDir{
        //ignore config-dirs
        println "Executing site:deploy task für $it/pom.xml"
        def processOutput="mvn.bat -f $it/pom.xml site-deploy".execute().text
        print processOutput

      > in some cases somehow the process hangs, i don't know why because the processOutput only gets displayed after
      > the process exited. how is it possible to print out continously the stdout/stderr of the process to the console
      > with "anyCommand".execute()?

      And this is from the JavaDoc for java.lang.Process:

      "Because some native platforms only provide limited buffer size for standard input and output streams, failure to promptly write the input stream or read the output stream of the subprocess may cause the subprocess to block, and even deadlock."

      Two simple solutions come to mind:
      (1) .getText() actively reads and buffers stderr and stdout in two separate threads.
      (2) Subclass java.lang.Process so that stderr and stdout are streams are overridden and read into buffered streams using separate threads.

      And, for extra credit, there are issues with synchronizing output between stderr and stdout. If you are reading both in separate threads and printing to console or a log file, the outputs can come in the wrong order depending on when the threads were executed, and in what order. Maybe there is a better way to solve this problem.

      Perhaps there is an easy way to pipe both into a StringBuffer???

      I am calling this a "critical" bug because being able to run external processes simply and elegantly is pretty central to any scripting-language-type uses, and the current implementation is clearly broken (but in a subtle way).




            paulk Paul King
            jasonsmith Jason Smith
            3 Vote for this issue
            2 Start watching this issue