Run JBoss as a Windows Service on BEA’s JRockit JVM using Java Service Wrapper - not JavaService

Now that's a long title, but still not long enough. It doesn't mention the "java.lang.OutOfMemoryError: PermGen space" errors that led to the use of BEA's JRockit as the JVM of choice for our application server.

After reading several resources (#1, #2, #3) we'd determined the cause of our PermGen Problems:

  • Continuous integration was causing frequent "Hot" deployment to our application server (Tomcat 5.5 then JBoss 4.0.4 - Same problem on both). We're crediting the JVM's garbage collecting for not correctly unloading the "old"/previously deployed classes, thus causing the PermGen to run out of space.
  • Using Cruise Control running on Jetty, every time the build ran, we'd get a PermGen OutOfMemoryError during JUnit test target execution. We're crediting JUnit for this problem due to the massive class creation/loading that it uses to provide it's much appreciated "clean" environment with every test.

We temporarily solved the problem by not deploying "Hot"; automatically restarting the server instead. The JUnit test problem was temporarily solved by increasing the Jetty server's max PermGen size using the -XX:MaxPermSize=128m JVM arg. Neither of these solutions are great. The most commonly suggested real solution to these problems is to switch to BEA's JRockit JVM - I guess it doesn't have a Permanent Generation memory space so it's impossible to get PermGen memory errors.

Our next step... Running JBoss on BEA's JRockit JVM as a Window's service using JavaService... This didn't work. Why? I have no idea. After a lot of searching for JavaService and JRockit recipes and only finding unanswered questions to a common problem, "...the service will install correctly, but it won't start..." (orsomethinglikethat), I gave Java Service Wrapper a try. I initially preferred JavaService for it's simplicity and small learning curve for the impatient, but Java Service Wrapper works (even with JRockit) and isn't too complicated after a little reading.

To summarize my ramblings to this point: If you're having PermGen memory problems, then BEA's JRockit JVM may be your answer - just don't try to use it in combination with JavaService. Use Java Service Wrapper instead. Here's how to configure Java Service Wrapper to run JBoss on JRockit: (assuming existing JBoss and JRockit installation)

  1. Download and extract Java Service Wrapper to {WRAPPER_HOME}.
  2. Copy the following: to {JBOSS_HOME}\bin
    • {WRAPPER_HOME}\bin\Wrapper.exe
    • {WRAPPER_HOME}\src\bin\App.bat - Rename to JBoss.bat
    • {WRAPPER_HOME}\src\bin\InstallApp-NT.bat.in - Rename to InstallJBoss-NT.bat
    • {WRAPPER_HOME}\src\bin\UninstallApp-NT.bat - Rename to UninstallJBoss-NT.bat
  3. Copy the following to {JBOSS_HOME}\server\{SERVER_INSTANCE}\lib
    • {WRAPPER_HOME}\lib\Wrapper.dll
    • {WRAPPER_HOME}\lib\wrapper.jar
  4. Copy {WRAPPER_HOME}\src\conf\wrapper.conf.in and rename to {JBOSS_HOME}\server\{SERVER_INSTANCE}\conf\wrapper.conf
  5. Use the following wrapper.conf properties contents:
    • wrapper.java.command=%JAVA_HOME%/bin/java
    • wrapper.java.mainclass=org.tanukisoftware.wrapper.WrapperSimpleApp
    • wrapper.jav.classpath.1=%JBOSS_HOME%/server/{SERVER_INSTANCE}/lib/wrapper.jar
    • wrapper.java.classpath.2=%JAVA_HOME%/lib/tools.jar
    • wrapper.java.classpath.3=c:/%JBOSS_HOME%/bin/run.jar
    • wrapper.java.library.path.1=c:/%JBOSS_HOME%/{SERVER_INSTANCE}/default/lib
    • wrapper.java.additional.1=-Dprogram.name=c:/%JBOSS_HOME%/bin/run.bat
    • wrapper.java.additional.2=-Xms128m
    • wrapper.java.additional.3=-Xmx512m
    • wrapper.java.additional.4=-Djava.endorsed.dirs=c:/%JBOSS_HOME%/lib/endorsed
    • wrapper.app.parameter.1=org.jboss.Main
    • wrapper.app.parameter.2=-c {SERVER_INSTANCE}
    • wrapper.ntservice.name=JBoss
    • wrapper.ntservice.displayname=JBoss Server

Repeat steps 3-6 for each server instance to configure as a service; replacing {SERVER_INSTANCE} with the actual name. The service(s) can now be installed by executing "{JBOSS_HOME}\bin\InstallJBoss-NT ..\server\{SERVER_INSTANCE}\conf\wrapper.conf" Make sure your %JAVA_HOME% is set to JRockit's home and %JBOSS_HOME% is set accordingly.

Spread the word... These icons link to social bookmarking sites where readers can share and discover new web pages.
  • DZone
  • Slashdot
  • Digg
  • del.icio.us
  • StumbleUpon
  • Reddit
  • Technorati

6 Comments so far

  1. Staffan Larsen on December 27th, 2006

    Thanks for the bugreport on JRockit and JavaService. I have filed a detailed bug with JavaService:

    http://forge.objectweb.org/tracker/index.php?func=detail&aid=306535&group_id=137&atid=350183

  2. Luke Pillow on December 27th, 2006

    Thanks for filing the report. I think you’ve really helped JavaService team out.

  3. John Hafner on February 1st, 2007

    We had the same problem with jboss memory leaks. Jrockit seems to fix them but I am having a problem getting the service to realize jboss has started. It gets stuck at “starting” even after:
    [Server] JBoss (MX MicroKernel) [4.0.5.GA (build: CVSTag=Branch_4_0 date=200610162339)] Started in 1m:21s:15ms

  4. segdztxoot on July 31st, 2007

    Hello! Good Site! Thanks you! hrubkbaqbp

  5. Andre on September 7th, 2007

    What version of JavaService and JRockit were you using? We’ve been running JavaService for years, and recently switched to JRockit (JRE 5.0 Update 11). We had no problems - we simply pointed the JVM Library option to the JRockit jvm.dll.

    We were still using an ancient version of JavaService (1.1). Maybe the problem was introduced later in JavaService?

  6. Luke Pillow on September 7th, 2007

    Andre,

    I do not recall what version of JavaService we were using. I would guess that it was 2.0.10 since that is the latest release as of 5/1/2006 and we were first trying this in December 2006. In an earlier comment, Stefan Larson from the JRockit development team had submitted a bug report regarding the issue with a proposed JavaService fix. That ticket is open and unassigned to this day.

    We were using JRockit (JRE 5.0 Update 6), so maybe the JRockit team has since accommodated the problem from their side.

Leave a reply