Plexus Utils
  1. Plexus Utils
  2. PLXUTILS-32

CommandLineUtils hangs when served interactive process execution

    Details

    • Type: Bug Bug
    • Status: Open Open
    • Priority: Blocker Blocker
    • Resolution: Unresolved
    • Affects Version/s: None
    • Fix Version/s: None
    • Labels:
      None
    • Environment:
    • Testcase included:
      yes
    • Number of attachments :
      2

      Description

      If I present a process that requires user input to the util classes, the execution will never end.

      There are in fact several threading and io bugs in the code. I've fixed most of them, but still lack one. Providing my current patch as I have to take a break, maybe someone will identify the correct way to solve the issue.

      The attached patch isn't yet complete as I don't manage to exactly reproduce the System.in behavior. Comments appreciated. I will look into that later this week-end or next week.

      Not sure if the problem is platform/JDK specific, haven't tried with other configurations Could be, so we need to find a solution that is resistant to external issues.

      [Gosh I am tired of having to fix these issues in all exec implementations... this is probably not supported by the CruiseControl implementations]

        Activity

        Hide
        Jerome Lacoste added a comment -

        Diagram representing the interaction of the various classes...

        Someone wants to add this to the doc ? Maybe for the cli package.html

        Show
        Jerome Lacoste added a comment - Diagram representing the interaction of the various classes... Someone wants to add this to the doc ? Maybe for the cli package.html
        Hide
        Jerome Lacoste added a comment -

        (note in the diagram above read StreamFeeder instead of SystemFeeder).

        I've some more changes on my local tree, but still no clear solution to the problem.

        The issue is coming from the StreamFeeder that blocks on the call to input.read(). Because it blocks, feed() doesn't terminate. And then inputFeeder.wait() blocks forever.

        Unfortunately I don't find a way to make sure read() stops hanging.

        I've tried:

        • closing the input stream (and I don't think this should be done anyway)
        • puting the inputFeeder to null and remove the call to wait(), to open that it would discard itself and be sufficient. That didn't help
        • I don't want to make it a daemon thread. Otherwise they would accumulate...
        • I've tried removing the direct call to read() and use an InputStreamReader.ready() call. It's better but doesn't cover all cases (i.e. it works with the official System.in, but doesn't work with other InputStream (probably because they don't support nio??)). So I don't like it. Maybe I missed something ?
        • I am now considering killing the thread.... Yack...

        There must be a way to do this properly....

        Show
        Jerome Lacoste added a comment - (note in the diagram above read StreamFeeder instead of SystemFeeder). I've some more changes on my local tree, but still no clear solution to the problem. The issue is coming from the StreamFeeder that blocks on the call to input.read(). Because it blocks, feed() doesn't terminate. And then inputFeeder.wait() blocks forever. Unfortunately I don't find a way to make sure read() stops hanging. I've tried: closing the input stream (and I don't think this should be done anyway) puting the inputFeeder to null and remove the call to wait(), to open that it would discard itself and be sufficient. That didn't help I don't want to make it a daemon thread. Otherwise they would accumulate... I've tried removing the direct call to read() and use an InputStreamReader.ready() call. It's better but doesn't cover all cases (i.e. it works with the official System.in, but doesn't work with other InputStream (probably because they don't support nio??)). So I don't like it. Maybe I missed something ? I am now considering killing the thread.... Yack... There must be a way to do this properly....
        Hide
        Jerome Lacoste added a comment -

        I looked at how other implementations do their work:

        CruiseControl assumes no input stream is used.

        Commons exec makes the Thread that reads the input a DaemonThread. But I am not sure if commons-exec has the same problem as p-u.
        http://svn.apache.org/repos/asf/jakarta/commons/sandbox/exec/trunk/src/main/java/org/apache/commons/exec/PumpStreamHandler.java

        Isn't there a part of maven that calls a process that interacts with the user ?

        Show
        Jerome Lacoste added a comment - I looked at how other implementations do their work: CruiseControl assumes no input stream is used. Commons exec makes the Thread that reads the input a DaemonThread. But I am not sure if commons-exec has the same problem as p-u. http://svn.apache.org/repos/asf/jakarta/commons/sandbox/exec/trunk/src/main/java/org/apache/commons/exec/PumpStreamHandler.java Isn't there a part of maven that calls a process that interacts with the user ?
        Hide
        Kristian Rosenvold added a comment -

        All the threading bugs have been fixed as part of other issues, the only bit left in this issue might be about termination when reading from the console.

        Show
        Kristian Rosenvold added a comment - All the threading bugs have been fixed as part of other issues, the only bit left in this issue might be about termination when reading from the console.

          People

          • Assignee:
            Unassigned
            Reporter:
            Jerome Lacoste
          • Votes:
            1 Vote for this issue
            Watchers:
            2 Start watching this issue

            Dates

            • Created:
              Updated: