Commons Launcher
  1. Commons Launcher
  2. LAUNCHER-1

[launcher] - on OutOfMemoryError no message

    Details

    • Type: Bug Bug
    • Status: Open
    • Priority: Critical Critical
    • Resolution: Unresolved
    • Affects Version/s: 1.0-dev (Tomcat)
    • Fix Version/s: None
    • Labels:
      None
    • Environment:

      Operating System: All
      Platform: All

      Description

      THERE IS NO PLACE TO LOG A BUG AGAINST THE commons-launcher CODE!!!!!!!!!!!!!!

      There is a rather bad bug in commons-launcher-0.9. Its bad
      if you want to get notified when the child JVM dies
      because of an Error (like java.lang.OutOfMemoryError).
      I need such information because I am using Java
      Service Wrapper,

      http://wrapper.tanukisoftware.org/doc/english/,

      which allows one to wrap their java code in a platform
      specific native wrapper which, for example, detects
      the printing of the string "java.lang.OutOfMemoryError"
      by the child JVM and restarts the child (if thats the
      behavior you want). Its a rather perfect fit with
      commons-launcher; I use the wrapper to launch the
      launcher and all of the java classpath, system
      properties, etc. variability is located in the
      java application specific launcher.xml file.
      Any way, the bug:
      When the child java application has an Error thrown,
      it propagates up the thread stack until it reaches
      the ThreadGroup class ExitOnErrorThreadGroup, which is
      a commons-launcher class. Here the ThreadGroup method,

      public void uncaughtException(Thread t, Throwable e)

      Is redefined to call the Launcher code to print out the
      Error object's information. Specifically, it calls,

      Launcher.error(Throwable e);

      Well, two problems.

      The first, and less serious, the parent java process, the one
      that executed ChildMain as a child java process, actually
      initialized the Launcher class' log - the child java process
      never initialized its own copy of the Launcher class' log.
      So if one expects the error message to go to the same place as
      the parent process' log - mayby it will maybe it won't.

      The second is a more serious problem. When the child java process
      gets to calling Launcher.error(e) for the first time, well
      this is the first time that the Launcher class has been loaded
      by the child process so it and all objects it depends upon
      must be loaded. Well, it uses Ant's project class so basically,
      the child process has to have Ant in its class path. If it does
      not, then the Error message is NEVER printed because a different
      exception is thrown while the JVM is trying to load the Ant
      class (since it can not find them since they are not on the
      classpath).

      If the Error message is NOT printed, then the Java Service
      Wrapper never sees the message and the Java application is
      not restarted - which is why I discoved the bug in the
      first place after some searching around.

      The solution:
      Recommending that users of the commons-launcher allways include
      Ant in their class path I think is a no starter.
      The solution I would like is for the ExitOnErrorThreadGroup
      class' uncaughtException(..) method simply to print
      the Error message to System.err.

        Activity

          People

          • Assignee:
            Unassigned
            Reporter:
            Richard
          • Votes:
            0 Vote for this issue
            Watchers:
            0 Start watching this issue

            Dates

            • Created:
              Updated:

              Development