In the first part of this TechTip, I showed you how to install and set up the open-source application server JBoss on System i. I also covered the steps necessary to deploy the sample EJB3Trail application. This time, I will walk you through the process of integrating the JBoss instance with i5/OS work management to provide better performance and manageability of the EJB3 applications.

The i5/OS work management is far superior to that of any other operating system with which I'm familiar in terms of its ability to assign various workloads into separate subsystems with dedicated system resources. A subsystem is a predefined operating environment entity that the system uses to coordinate the work flow and resource use. In addition, a memory pool can be used to further separate the workloads. A memory pool is a division of main storage, and it can be assigned to a subsystem so that the jobs running in a given subsystem do not have to compete for memory access with jobs in other subsystems.

Now, I will use these fundamental concepts to create a shared memory pool and a separate subsystem for the JBoss application server.

Setting Up a Shared Memory Pool

The i5/OS supports both shared and private memory pools. The shared pools are more flexible, because they allow sharing of unused memory between pools and they can also use the Expert Cache. The Expert Cache is a disk cache tuner that can reduce the time to process disk I/O. The i5/OS contains 64 predefined shared pools that can be allocated to subsystems. You can use either the graphical iSeries Navigator or the CL commands to configure a shared pool. To save space (and time?), I use CL commands in the course of this TechTip.

You can use the Work with Shared Pools (WRKSHRPOOL) command to configure the shared pool for JBoss. The command displays the names and status of the shared pools. The first four pools on the list are predefined by IBM, so you need to choose one of the other pools labeled *SHRPOOL1 through *SHRPOOL60. Locate the specific pool you want to configure, say *SHRPOOL2. You need to set three parameters:

• Defined Size (M)—This is the amount of main storage, in megabytes, defined, for the pool. The memory requirement depends on the application. A good starting point would be 1.5–2 GB of memory for a good-sized application server. Then, monitor the paging rates to see if the memory size is adequate for your environment.
• Maximum Active—This identifies the maximum number of threads that can use the processor concurrently. Set this parameter to 500.
• Paging Option—The paging option determines whether the system should dynamically adjust the paging characteristics of the pool for optimum performance. Set it to *CALC to enable Expert Cache tuning.

Alternatively, you could execute the following Change Shared Pools (CHGSHRPOOL) command:

Setting Up the JBoss Subsystem

The process of creating a subsystem is pretty straightforward. First, I use the Create Subsystem Description (CRTSBSD) command:

CRTSBSD SBSD(JBOSS4/JBOSS4) POOLS((1 *SHRPOOL2)) TEXT('JBoss 

processing subsystem')

For simplicity, I keep all JBoss work management objects in a separate

 library called JBOSS4. I also instruct the system to use the memory 

from the *SHRPOOL2 storage pool to service the jobs running in this subsystem.  

I create a unique job queue that is used to queue up jobs waiting to be 

processed in the new subsystem. Here's the Create Job Queue (CRTJOBQ) 

command that accomplishes this task:

CRTJOBQ JOBQ(JBOSS4/JBOSS4JOBQ) TEXT('Job queue for the JBOSS4 processing subsystem')  

The Add Job Queue Entry (ADDJOBQE) command associates the newly created job queue with the subsystem:

The MAXACT parameter specifies that only one job from the job queue can be active at any time. This ensures that only one JBoss instance can be started from this job queue.

I use the Create Class (CRTCLS) command to create a class object that specifies the processing attributes for the jobs that use that class:

The Run Priority parameter is set to 20, which is as high as the priority of interactive jobs.

I then use the Add Routing Entry (ADDRTGE) command to create a routing entry for the subsystem. A subsystem can have more than one routing entry; however, each job uses a single routing entry. Subsystems select which routing entry to use based on the comparison value in the routing entry and the routing data string in the job. Routing entries assign a pool and a class to a job while it is being started. In this case, I want the subsystem to invoke the command processor (QCMD) to run any submitted command. Here's the command to add the necessary routing entry:

The Sequence Number (SEQNBR) parameter is set to 9999, which is the maximum, catch-all value. Routing entries are searched in ascending sequence number order. So sequence 9999 is processed only if there is no match for any lower sequence number. The Comparison Data (CMPVAL) parameter specifies the string that is used to compare with the routing data to determine which routing entry is applied. The *ANY value means that any routing data is considered a match.

To have the JBoss application server start automatically after the subsystem is started, I attach an autostart job entry to the subsystem. First, however, I need to create a job description for the autostart job. An autostart job description contains all the runtime environment parameters needed to run the job. I use the Create Job Description (CRTJOBD) command to accomplish this task:

The User parameter specifies the name of the user profile associated with
this job description. The Request Data (RQSDTA) parameter is the actual command string that i5/OS should execute. In this case, the Submit Job (SBMJOB) command is used to invoke the QShell processor. A QShell script name is passed as an input parameter to the QShell processor. (The content of this script is explained in the next section.) The Job Queue (JOBQ) parameter is used to point to a job queue associated with the subsystem, in which the job is to be executed. Finally, the Allow Multiple Threads (ALWMLTTHD) parameter set to *YES specifies that the job can run with multiple user threads. This is required, because JBoss is a multithreaded Java application.

The runServer.sh QShell script is used to set up the run-time environment for JBoss and to invoke the script to start the application server. The source of the script is listed below:

At [1] in the code above, the path to the JBoss executable code is appended to the CLASSPATH environment variable. At [2], the JAVA_HOME variable is set so that the 32-bit IBM J9 JVM is enabled (see part 1 of this tip for more details). At [3], the run.sh script is invoked to start the application server.

Once the necessary job description is defined, I can use the Add Autostart Job Entry (ADDAJE) command to attach an autostart job entry to the JBoss subsystem:

The entry identifies the job name and the job description to be used to automatically start a job that initializes the application server.

Now I can start the JBoss subsystem with the following command:

To verify that the subsystem started successfully, I use the Work with Active Jobs (WRKACTJOB) command:

The dialog that appears is shown in Figure 1.

Figure 1: The WRKACTJOB dialog will show whether the subsystem started successfully. (Click image to enlarge.)

The presence of the batch immediate job named QP0ZSPWP with the function set to JVM-org.jboss indicates that the JBoss application server is running.

To stop the server, I can use the following command:

Additional Material

The process of installing the JBoss application server and the sample EJB3 application is covered in the first part of this tip: "TechTip: Explore and Leverage EJB3 on System i Now!"

Jarek Miszczyk is the Senior Software Engineer, ISV Solutions Enablement, IBM Rochester. He can be reached by email at This e-mail address is being protected from spam bots, you need JavaScript enabled to view it .