Plexus Utils

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

Ascending order - Click to sort in descending order
Hide
Permalink
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
Permalink
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
Permalink
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
Permalink
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
Vote (1)
Watch (2)

Dates

  • Created:
    Updated: