Posts tagged production

JBoss is a free and open source Java based application server widely used. Since it is Java based, it is supported in a wide range of platforms. JBoss can be used in large scale deployment and supports clustering, load balancing, Enterprise Java Beans and almost all latest J2EE specifications. The current production version is 5.1.* and a new version (6+) will turn GA (Generally Available/Baseline) soon.

JBoss works “out of the box” and applications can be deployed just by dropping application WAR/EAR files to the application server’s deploy folder. But in order to use JBoss in a production server, it is necessary to configure/tune a number of application server settings. In this article I will quickly cover all the important production settings for JBoss.

This article assumes that you are hosting JBoss in a Windows 2003 Server. The steps are similar in Unix/Linux systems(Ubuntu, Fedora etc).

Prerequisites

Before we take up any of the following steps, it is necessary to fix the JBoss version to be used, the JVM version, the platform for hosting JBoss and whether clustering is required. These decisions are dependent on application requirements and current enterprise architecture of the customer. In the examples below I use JBoss 4.2.1(4.2.2) version with Java Virtual Machine 1.5 and Windows 2003 server as hosting platform.

Also note the JBoss folder structure given on the right side (see figure). The following sections refer to various folders shown in this.

Configuring JBoss in a Production Server – Step by Step Guide

Step 1 – Configuring Startup Scripts

The first thing I did was to create a set of startup/shutdown scripts for JBoss Server. These were copied to the desktop so that it is easy to start or stop the JBoss instance.

startjboss.cmd

d:

cd D:\server\jboss-4.2.2.GA\bin
run.bat -b 0.0.0.0
stopjboss.cmd

d:

cd D:\server\jboss-4.2.2.GA\bin
shutdown.bat -S

As you can see both these scripts are actually calling default scripts provided in the JBoss’ bin folder.

In the startup script the -b argument (binding ip) indicates the IP to which the server session is to be attached. 0.0.0.0 indicates that the server must be accessible from all ips including localhost (it binds the JBoss server to all ip addresses of server machine). If you don’t specify this, JBoss will be accessible only from 127.0.0.1.

Step 2 – Configuring JVM Memory Settings

The run.bat file in the bin folder contains JVM parameters including memory configuration. In the production server, ensure that these values are correctly set. For example, the following sets the minimum and maximum heap size as 1GB. It is better to keep them identical for performance reasons. The actual heap size setting will depend on your application requirements and also on the RAM size of the server machine.

set JAVA_OPTS=%JAVA_OPTS% -Xms1024m -Xmx1024m

Also ensure that adequate permgen space is set. Permgen space is the fixed memory required such as the code footprint. For large applications the default value of 64m may not be sufficient. Following sets the permgen space to 512MB.

set JAVA_OPTS=%JAVA_OPTS% -XX:PermSize=512m -XX:MaxPermSize=512m

Step 3 – Changing Default HTTP Port to 80

The HTTP port for default JBoss installation is 8080. In production server, you will require this to be on port 80 (default HTTP port). If you are using HTTPS, you will need to change SSL port from 8443 to 443. Following files must be edited for this change. Look for the “Connector” tag with “port” attribute.

(a) default/deploy/jboss-web.deployer/server.xml
(b) default/deploy/http-invoker.sar/META-INF/jboss-service.xml
(c) default/deployers/jbossweb.deployer/server.xml
(d) default/deploy/jbossws.sar/jbossws.beans/META-INF/jboss-beans.xml

Step 4 – Configuring Datasource Settings

The datasource settings are stored in xml files under deploy folder of the server. For example, oracle-ds.xml is the configuration file I used in my application. This maps a connection setting to a JNDI name. The important parameters to configure are,

min-pool-size – This is the initial number of connections kept open to database.
max-pool-size – This is the maximum number of concurrent connections possible to the database. This value should be based on your application needs and also on the database configuration.

Step 5 – Configuring HTTP Connector Settings

The underlying HTTP connector of JBoss needs to be fine tuned for production settings. The important parameters are,

maxThreads – This indicates the maximum number of threads to be allocated for handling client HTTP requests. This figure corresponds to the concurrent users that are going to access the application. Depending on the machine configuration, there is a physical limit beyond which you will have to do clustering.

acceptCount – This is the number of request threads that are put in request queue when all available threads are used. When this exceeds, client machines get a request timeout response.

compression – If you set this attribute to “force”, the content will be compressed by JBoss and will be send to browser. Browser will extract it and display the page on screen. Enabling compression can substantially reduce bandwidth requirements of your application.

Step 6 – Configuring JSP Compilation Settings

JBoss application server regularly checks whether a JSP requires compilation to a servlet before executing a JSP. In a production server, JSP files won’t change and hence you can configure the settings for increased performance.

Open the web.xml in deploy/jboss-web.deployer/conf folder. Look for the jsp servlet in the file and modify the following XML fragment as given below,

<init-param>
<param-name>development</param-name>
<param-value>false</param-value>
</init-param>
<init-param>
<param-name>checkInterval</param-name>
<param-value>300</param-value>
</init-param>

Step 7 – Removing unwanted applications and services

JBoss comes with a lot of services and your enterprise applications may not need all of them. Removing these unwanted services can boost application server performance. Following are some of the JBoss services you can remove if your application is not using them. Delete the files/folders given in brackets to remove these services completely.

(a) Home page server- (deploy/ROOT.war)
(b) JMX Console server – (deploy/jmx-console.war)
(c) Web Console server – (deploy/management)
(d) Unique ID key generator – (deploy/uuid-key-generator.sar, lib/autonumber-plugin.jar)
(e) HTTP Invoker service – (deploy/http-invoker.sar)
(f) Quartz scheduler service – (deploy/quartz-ra.rar)
(g) Mail service – (deploy/mail-service.xml, lib/mail*.jar)
(h) Monitoring service – (deploy/monitoring-service.xml,lib/jboss-monitoring.jar)
(i) Scheduler service – (deploy/scheduler-service.xml, deploy/schedule-manager-service.xml,lib/scheduler-plugin*.jar)
(j) Messaging (JMS) service – (deploy/messaging, deploy/jms-ds.xml, deploy/jms-ra.rar, lib/jboss-messaging*.jar)

Step 8 – Protecting Administration Console Applications

Some of the default Web applications in JBoss are very useful in monitoring server status. For example the Web Console can give valuable information such as server memory status and active HTTP active connections. Please see the Web Console screenshot below (http://localhost/web-console/),

So you may decide to leave them enabled on the JBoss production server. But the problem is that these can be accessed by anyone through Internet and is unprotected.

You can protect these applications using JAAS or by limiting access to these applications only from the local machine (server machine). Of course the easiest way to secure them is to remove them as I have shown in the previous section. In order to enable access only from local machine,

Add the following in server.xml (jboss-web.deployer) just before “Engine” closing tag.

<Host name=”loopback” autoDeploy=”false” deployOnStartup=”false” deployXML=”false”>
</Host>

Then add the following in jboss-web.xml in WEB-INF of the following admin applications.

loopback

For JMX Console use deploy/jmx-console.war and for Web Console use deploy/management folder. Now these monitoring apps can be accessed only from http://loopback address.

Step 9 – Configuring Log4J Logging for Production

The default logging configuration in JBoss is not suitable for production deployment. In production, you only want the errors to be logged. Open jboss-log4j.xml file in deploy/conf folder.

First change the root category in the end to contain only FILE appender. This ensures that there is logging to the screen and all errors are only logged to a file.

<root>
<appender-ref ref=”FILE”/>
</root>

Then add the following limiting categories.

<category name=”org”>
<priority value=”ERROR”/>
</category>
<category name=”com”>
<priority value=”ERROR”/>
</category>
<category name=”net”>
<priority value=”ERROR”/>
</category>

Remove the following entries,

<category name=”org.apache”>
<priority value=”INFO”/>
</category>
<category name=”org.quartz”>
<priority value=”INFO”/>
</category>
<category name=”org.jboss.management”>
<priority value=”INFO”/>
</category>
<category name=”org.jboss.serial”>
<priority value=”INFO”/>
</category>