[jira] Created: (LAUNCHER-5) Commons Launcher & Excessive CPU Consumption

["Rick Moynihan (JIRA)" <ji...@apache.org>]

Commons Launcher & Excessive CPU Consumption
--------------------------------------------

                 Key: LAUNCHER-5
                 URL: https://issues.apache.org/jira/browse/LAUNCHER-5
             Project: Commons Launcher
          Issue Type: Bug
    Affects Versions: Nightly Builds, 1.0 Alpha
         Environment: x86 Linux (Ubuntu 6, Redhat 9) , Solaris 8/9 (SPARC).  Probably all non windows OS's.
            Reporter: Rick Moynihan


I have diagnosed a performance issue with a network service we are starting
via commons launcher.

The problem is that the service starts excessively consuming CPU cycles
to the point at having near 100% utilisation (as shown by top).

At first I thought it was in some of our code, but after running hprof I
 managed to trace the problem into Commons Launcher.  After searching
the commons mail archives I uncovered this post concerning what looks to
be precisely the issue I have diagnosed.  My hprof results are almost
identical.

I am running this on Linux with Java 1.5.0-b64, though I have
experienced what appears to be the same problem under 1.4 vm's and also
on Solaris 9.  To my knowledge Windows does not suffer from this.

It appears to me that this issue seems to have been unresolved, is this
true?  Commons Launcher also seems to be suffering from a lack of usage
and community, has it been abandoned??  Is it still being used by the
Tomcat community?  If so have they resolved this issue or not?

I have done some digging in the commons launcher source code and have
found that the ParentListener class seems to be the root of the problem.
  The javadoc class description describes ParentListener as  "A class
for detecting if the parent JVM that launched this process  terminated."

On Unix/Linux the problem appears to be the following code:

// Cache System.in in case the application redirects
InputStream is = System.in;
int bytesAvailable = 0;
int bytesRead = 0;
byte[] buf = new byte[1024];
try {
    while (true) {
        synchronized (is) {
            // Mark the stream position so that other threads can
            // reread the strea
            is.mark(buf.length);
            // Read one more byte than has already been read to
            // force the stream to wait for input
            bytesAvailable = is.available();
            if (bytesAvailable < buf.length) {
                bytesRead = is.read(buf, 0, bytesAvailable + 1);
                // Reset so that we "unread" the bytes that we read
                is.reset();
                if (bytesRead == -1)
                    break;
            } else {
                // Make the buffer larger
                if (buf.length < Integer.MAX_VALUE / 2)
                    buf = new byte[buf.length * 2];
            }
        }
        yield();
    }
} catch (IOException ioe) {}

Note that this loops forever until the input stream returns -1
(presumably on it's closing).  Despite the call to yield() I fear that
the problem is that this loop is incredibly tight and is what is causing
the CPU drain.  Is there anyway that this can be efficiently alleviated?
  Perhaps rather than using the classical java.io it could be moved to
use java.nio?  Would this not remove the requirement to fire off a
separate thread?  I believe that Java NIO was introduced in Java 1.4.2,
does launcher need to support versions prior to this?

Any thoughts on the best way to resolve this issue would be highly
appreciated.

Also, I can't seem to find a working email address for any of the Launcher
developers.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org