In one of my projects I have got some time to play with JBoss to “tune” it. I will rather say to “slim” it!
The project was basically a JEE application involving EJB 3.0 and Flex with BlazeDS. Here are some of the things which I noticed / performed …
- Use latest version of JBoss (jboss-5.1.0.GA-jdk6 if using Java 6. You would face problems related to web services java.lang.UnsupportedOperationException: setProperty
must be overridden by all subclasses of SOAPMessage something of this sort if you try to use JBoss 5 with Java 5. Refer: http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4194526 … Thanks Ashwin Shah for figuring out this!) - Set following JVM arguments in run.conf.bat
- set "JAVA_OPTS=-Xms512M -Xmx512M -XX:MaxPermSize=256M -XX:PermSize=256M -XX:ReservedCodeCacheSize=128M"
- The meaning of above parameters can be found at http://java.sun.com/javase/technologies/hotspot/vmoptions.jsp
- Above settings are for me and you may have your own values for JVM parameters.
- To know overall Java memory management or garbage collection search google!
- Configure log4j as …
- Use minimum required pattern as
param name="ConversionPattern" value="%d{yyyy MM dd HH:mm:ss:SSS}, [%-5p], [%t:%x], %c, %m%n"- Use INFO threshold by setting property in run.conf.bat as
set "JAVA_OPTS=-Djboss.server.log.threshold=INFO"- Disable console logs as
just XML comment: appender-ref ref="CONSOLE"
- Slim web container as
- If AJP connector is not getting used then disable its "connector" entry from server.xml
- If only HTTPS is used and not HTTP then disable HTTP "connector" entry from server.xml
- Remove unused services by removing following files from JBoss default configuration
- cache-invalidation-service.xml (needed in case of clustered deployment)
- hdscanner-jboss-beans.xml (hot deployment related)
- http-invoker.sar (invoking rmi over http)
- monitoring-service.xml (monitoring alerts)
- profileservice-jboss-beans.xml (profile service)
- profileservice-secured.jar (profile service)
- properties-service.xml (setting jmx properties)
- quartz-ra.rar (scheduler)
- schedule-manager-service.xml (scheduler)
- scheduler-service.xml (scheduler)
- uuid-key-generator.sar (uuid generator)
- Remove Jboss timer services (ejb2-timer-service.xml and ejb3-timerservice-jboss-beans.xml) if not using MDB. If the bug https://jira.jboss.org/jira/browse/EJBTHREE-1880 gets fixed then you can remove timer services even if you are using MDB
- Well there are many more things which can be found at
- That’s it! (More things coming later … when? Don’t know ;-))
Some explanation on "JVM not able to create native threads":There is a nice article which talks about this issue:
http://www.egilh.com/blog/archive/2006/06/09/2811.aspxThe article summary is as follows
- Let’s say we have a 32 bit Windows machine with 4 GB of RAM. In 32 bit windows every process has a max limit of 2 GB virtual memory. So the JVM has a max limit of 2 GB.
- If we have allocated 1.5 GB memory to JVM heap then only 500 MB memory is still available to JVM. Out of this say JVM use 100 MB for other purposes like linking etc then JVM has 400 MB left.
- In java when we create a thread, java creates a thread object in JVM memory and also creates operating system thread. Now from java 1.5 onward each thread has its own stack of 1 MB.
- So according to above statistics, JVM is only able to create maximum 400 threads using 400 MB memory left. And if thread count is increased JVM would give an error “unable to create native threads”!.
- Hence we have to decrease the JVM heap memory size to increase the thread count.
Hope this helps!
