JBoss 5.x Tuning/Slimming

Introduction

The following slimming recommendations are for a standard JBoss AS 5.1.0 GA (Community) "All" configuration and can be used for Jboss EAP 5.1.0 (Enterprise).

Slimming is very application specific, so this is by no means a universal document. If you have documented the process for slimming other services for JBoss 5.x please add to them here.

Slimming

Remove EJB3 services

In server /<node>/deploy/
remove:

• ejb3-connectors-jboss-beans.xml
• ejb3-container-jboss-beans.xml
• ejb3-interceptors-aop.xml
• ejb3-timerservice-jboss-beans.xml
• profile-service-secured.jar -  Note : this folder is not in Jboss EAP 5.1.0

In server /<node>/deployers/
remove:

• jboss-ejb3-endpoint-deployer.jar
• ejb3-deployers-jboss-beans.xml --> Note : this file is in Jboss EAP 5.1.0 but not Jboss AS 5.1.0

WARNING :

• Do not remove

1. deployers/ejb3.deployer/jboss-ejb3-deployer.jar
2. deployers/ejb3.deployer/META-INF/ejb3-deployers-jboss-beans.xml,

they are used to support annotations for EJB client.

Remove EJB2 services

In server/<node>/deploy/
remove:

• ejb2-container-jboss-beans.xml
• ejb2-timer-service.xml (Note that EJB3 deployments may fail without this service.  See this forum post)

Remove JUDDI

In server/<node>/deploy/ 
remove:

• juddi-service.sar

Remove Key Generator

In server/<node>/deploy/
remove:

• uuid-key-generator.sar

Remove JMS (Java Message Service)

In server/<node>/conf/props/
remove:

• messaging-roles.properties
• messaging-users.properties

In server/<node>/deploy/
remove:

• messaging
• jms-ra.rar
• quartz-ra.rar (this is just JMS resource to the Quartz scheduler)

In server/<node>/deployers/
remove:

• messaging-definitions-jboss-beans.xml

In server/<node>/conf/standardjboss.xml
remove (comment out):

• everything about jms (maybe optionnal because profile web and default use the same standardjboss.xml file and profile web have no JMS support)

In server/<node>/conf/jbossts-properties.xml
remove (comment out):

<property name="com.arjuna.ats.jta.recovery.XAResourceRecovery.JBMESSAGING1"
     value="org.jboss.jms.server.recovery.MessagingXAResourceRecovery;

           java:/DefaultJMSProvider"/> 
</properties>

Remove JBoss Mail

In server/<node>/deploy/
remove:

• mail-service.xml
• mail-ra.rar

Remove JBoss Scheduling

In server/<node>/deploy/
remove:

• schedule-manager-service.xml
• scheduler-service.xml

Remove Hypersonic DB

In server/<node>/deploy/
remove:

• hsqldb-ds.xml

Remove Bsh Deployer

In server/<node>/deployers/
remove:

• bsh.deployer

Turn off hot deployment

In server/<node>/deploy/
remove:

• hdscanner-jboss-beans.xml

Remove JBossWS

In server/<node>/conf
remove:

• jax-ws-catalog.xml

In server/<node>/conf/props/
remove:

• jbossws-roles.properties
• jbossws-users.properties

In server/<node>/deploy/
remove:

• jbossws.sar
• jbossws-console.war

In server/<node>/deployers/
remove:

• jbossws.deployer

Remove Seam

In server/<node>/deployers/
remove:

• seam.deployer
• webbeans.deployer

In server/<node>/deploy/
remove:

• admin-console.war - takes too much resources in JBoss 5.x, remove it even if you use Seam

Remove IIOP/Corba

In server/<node>/conf/
remove:

• jacorb.properties

In server/<node>/deploy/
remove:

• iiop-service.xml

In server/<node>/deployers/ejb3.deployer/META-INF
remove:

• ejb3-iiop-deployers-jboss-beans.xml

In server/<node>/lib 
remove:

• jacorb.jar

In server/<node>/conf/jndi.properties,
replace the line :

java.naming.factory.initial=org.jboss.iiop.naming.ORBInitialContextFactory

with this new line

java.naming.factory.initial=org.jnp.interfaces.NamingContextFactory

Remove other services

In server/<node>/deployers/ 
remove:

• xnio.deployer - not used in JBoss 5.x default configuration for  JBooss remoting anyway

In server/<node>/deploy/ 
remove:

• jboss-xa-jdbc.rar - if you do not use XA datasources
• jmx-remoting.sar - remote (RMI) acces to JMX, you can still access JMX by jmx-console
• jmx-console.war - if you do not use JMX console
• profileservice-secured.jar - secured remote access to profileservice
• sqlexception-service.xml - pretty useless in JBoss 5.x
• xnio-provider.jar - not used in JBoss 5.x default configuration for JBooss remoting

In server/<node>/deployers/  
remove:

• hibernate-deployer-jboss-beans.xml - deployment of HAr archives only, you can still use Hibernate in EJBs after you remove this

Also, feel free to remove the corresponding .jars for the services slimmed above from jboss/common/lib.

Remove Unused Invokers

It depends, which invoker you would like to use: jrmp, pooled, unified, http.

The best way is to chose one and disable the others.

TODO: how to switch invokers (such as switching JMX from JRMP to HTTP).

HTTP Invokers 

• If you want to remove the HTTP invokers (which are used if you 'tunnel' your requests through HTTP) simply remove the according deployments/directories from the $JBOSS_HOME/server/<profile>/deploy/ directory. 
• Please be aware that HTTP invokers are something different than the Tomcat HTTP Connector (the HTTP invokers need the HTTP connector but the HTTP connector does not need the HTTP invokers). 
• HTTP Invoker for JNDI, EJB and JMX
  • Simply remove the http-invoker.sar (web, default, standard) or httpha-invoker.sar (all, production) directory from your configuration all together.
  • If using a clustered configuration, then remove httpha-invoker.sar
• HTTP Invoker for JMS 
  • Remove the /deploy/jms/jbossmq-httpil.sar directory completely.

JMX Invoker

• If you want to remove the JMX invoker, remove $JBOSS_HOME/server/<profile>/deploy/jmx-invoker-service.xml.
• By removing the JMX invoker you will not be able to perform a remote shutdown or any sort of programmatic remote management.  You will not be able to use twiddle and shutdown scripts!
• The JMX invoker depends on the JRMP invoker.  You can remove the JMX invoker and keep the JRMP invoker, but you can't remove the JRMP invoker without removing the JMX invoker also.
• The legacy Web Management Console depends on the jmx-invoker service. You can remove the $JBOSS_HOME/server/<profile>/deploy/management directory in order to clean up deployment errors from this dependency.  This Web Console is deprecated by the Admin Console as of EAP 5 and is maintained for legacy purposes only.
• Securing the JMX Invoker
  • Rather than remove the jmx invoker, you can also secure it by uncommenting the line in jmx-invoker-service.xml that looks like:  <!-- <interceptor code="org.jboss.jmx.connector.invoker.AuthenticationInterceptor" securityDomain="java:/jaas/jmx-console"/> -->
  • This will require authentication to use the JMX invoker service, but the password will still be unencrypted.  You can implement a simple hashing method as shown in the security guide.

Pooled Invoker

• This provides a socket connection pool for remote EJB calls.
• If you want to remove the Pooled invoker, in server/<node>/deploy/legacy-invokers-service.xml remove (comment out): PooledInvoker

JRMP Invoker

• The org.jboss.invocation.jrmp.server.JRMPInvoker class is an MBean service that provides the RMI/JRMP implementation of the Invoker interface. The JRMPInvoker exports itself as an RMI server so that when it is used as the Invoker in a remote client, the JRMPInvoker stub is sent to the client instead and invocations use the RMI/JRMP protocol.
• If you want to remove the JRMP invoker, in server/<node>/deploy/legacy-invokers-service.xml remove (comment out): JRMPInvoker
• You also have to disable jmx-invoker-service.xml. See above.

IIOP Invoker

• JBoss IIOP supports CORBA/IIOP access to enterprise beans deployed in a JBoss Application Server, as defined by the EJB specification.
• If you want to remove the IIOP invoker, in server/<node>/conf/standardjboss.xml remove (comment out): invoker-proxy-binding iiop

Note: There may be other invokers bound to different ports. If you don't need them you may remove them. Otherwise secure them if they are reachable by folks you don't fully trust.

Remove Clustering

In server/<node> 
remove:

• deploy-hasingleton/
• farm/

In server/<node>/deploy
remove:

• cluster/

To eliminate an otherwise harmless error message in the logs about a missing farm directory,

in server/<node>/conf/bootstrap/profile.xml

edit the "BootstrapProfileFactory" bean and delete or comment out the following:

<!-- Optional list of URIs that will be kept in sync across the cluster.
     Requires deploy/cluster/farm-deployment-jboss-beans.xml to be
     deployed as well.
-->

 
<property name="farmURIs">
   <list elementClass="java.net.URI">
      <value>${jboss.server.home.url}farm</value>
   </list>
</property>

To switch JBoss Messaging to non-clustered operation, in server/<node>/deploy/messaging edit the <somename>-persistence-service.xml file and

• turn off clustering:

<attribute name="Clustered">false</attribute>  

• delete or comment out the dependency on the JGroups channel factory

<depends optional-attribute-name="ChannelFactoryName">
jboss.jgroups:service=ChannelFactory</depends>

The above describes a complete elimination of clustering features. Finer grained elimination of features can be accomplished by not completely deleting server/<node>/deploy/cluster but rather only deleting some of the deployments therein. For example, doing all of the above but leaving

• server/<node>/deploy/cluster/jboss-cache-manager.sar and
• server/<node>/deploy/cluster/jgroups-channelfactory.sar

will allow HttpSession replication to work.

Tuning

Reduce memory usage:

There's one very simple change that you could do to bring down the memory used by JBoss AS 5.1.0. By default, JBoss AS5 has some debug level MBeans (which are in most cases meant for JBoss server developer's use) enabled.

These MBeans are too much in number and are known to increase memory usage.

What you can do is, change the following from

JBOSS_HOME/server/< servername>/conf/bootstrap/deployers.xml:

<bean name="Deployers">
 <annotation>@org.jboss.aop.microcontainer.aspects.jmx.JMX(name=jboss.deployment:

  service=DeployersImpl, 

  exposedInterface=org.jboss.deployers.plugins.deployers.DeployersImplMBean.class, 

  registerDirectly=true)
</annotation> 

<constructor> 

   <parameter>

     <inject bean="jboss.kernel:service=KernelController"/>

   </parameter>

 </constructor>
 <!-- Accept any implementor of deployer -->
 <incallback method="addDeployer"/>
 <uncallback method="removeDeployer"/>
 <property name="mgtObjectCreator"> 

    <inject bean="ManagedObjectCreator"/>

 </property>
</bean>

to:

<bean name="Deployers">
 <!-- Uncomment the following @org.jboss.aop.microcontainer.aspects.jmx.JMX to enable 

 registering MC beans as MBeans. 

 These MBeans provide debug level information about which deployers were selected for
 processing the deployment and what attachments were added to the deployment. 

 More details 

 http://www.jboss.org/index.html?module=bb&op=viewtopic&t=155074&start=10#4233874
 --> 

<!--
 <annotation>@org.jboss.aop.microcontainer.aspects.jmx.JMX

 (name="jboss.deployment:service=DeployersImpl", 
  exposedInterface=org.jboss.deployers.plugins.deployers.DeployersImplMBean.class, 

  registerDirectly=true)
</annotation>
--> 

<constructor> 

      <parameter> 

          <inject bean="jboss.kernel:service=KernelController"/> 

      </parameter> 

</constructor>
 <!-- Accept any implementor of deployer -->
 <incallback method="addDeployer"/>
 <uncallback method="removeDeployer"/>
 <property name="mgtObjectCreator"> 

       <inject bean="ManagedObjectCreator"/> 

  </property>
</bean>

 

MVC - Application design in swing like framework (i.e. nextapp Echo3)

Figure1. A Common MVC Implementation

 

 Interaction Between MVC Components

 

Once the model, view, and controller objects are instantiated, the following occurs:

1. The view registers as a listener on the model. Any changes to the underlying data of the model immediately result in a broadcast change notification, which the view receives. This is an example of the push model described earlier. Note that the model is not aware of the view or the controller -- it simply broadcasts change notifications to all interested listeners.
2. The controller is bound to the view. This typically means that any user actions that are performed on the view will invoke a registered listener method in the controller class.
3. The controller is given a reference to the underlying model.

Once a user interacts with the view, the following actions occur:

1. The view recognizes that a GUI action -- for example, pushing a button or dragging a scroll bar -- has occurred, using a listener method that is registered to be called when such an action occurs.
2. The view calls the appropriate method on the controller.
3. The controller accesses the model, possibly updating it in a way appropriate to the user's action(accessing to the backend service for instance)
4. If the model has been altered, it notifies interested listeners, such as the view, of the change. In some architectures, the controller may also be responsible for updating the view. This is common in Java technology-based enterprise applications.

Figure 2 shows this interaction in more detail.

Figure 2. A Java SE Application Using MVC

The model does not carry a reference to the view but instead uses an event-notification model to notify interested parties of a change. 

One of the consequences of this powerful design is that the many views can have the same underlying model. When a change in the data model occurs, each view is notified by a property change event and can update itself accordingly. 

For example, Figure 3 shows two views that use the same data model.

Figure 3. Multiple Views Using the Same Model

Modifying the MVC Design

 

A more recent implementation of the MVC design places the controller between the model and the view. This design, which is common in the Apple Cocoa framework, is shown in Figure 4.

Figure 4. An MVC Design Placing the Controller Between the Model and the View

The primary difference between this design and the more traditional version of MVC is that the notifications of state changes in model objects are communicated to the view through the controller. (that means the controller will be the model changes listener instead of the views component, to decouple better the model from the view)

Hence, the controller mediates the flow of data between model and view objects in both directions. View objects, as always, use the controller to translate user actions into property updates on the model. 

In addition, changes in model state are communicated to view objects through an application's controller objects.

Thus, when all three components are instantiated, the view and the model will both register with the controller. Once a user interacts with the view, the events are nearly identical:

1. The view recognizes that a GUI action -- for example, pushing a button or dragging a scroll bar -- has occurred, using a listener method that is registered to be called when such an action occurs.(as the old design)
2. The view calls the appropriate method on the controller.(as the old design)
3. The controller accesses the model, possibly updating it in a way appropriate to the user's action.(as the old design)
4. If the model has been altered, it notifies interested listeners of the change. However, in this case, the change is sent to the controller.

Why adopt this design? Using this modified MVC helps to more completely decouple the model from the view. In this case, the controller can dictate the model properties that it expects to find in one or more models registered with the controller. In addition, it can also provide the methods that effect the model's property changes for one or more views that are registered with it.

The Hierarchical MVC

Why isn’t this enough ?
 
The MVC is an excellent basis on which to build a graphical application,however, as if stands it is not a complete solution. The basic problem is that,in general, if you tried to use just one Controller, one Model and one View for your whole application, the result would be unmanageable. 

For example, let us imagine that we were trying to build an email tool. 
With one single model we might be trying to represent;

· Read, unread, deleted, pending emails
· Address books
· Emails under construction
· The POP or SMTP configurations
· The sender’s profile (eg. name, return email etc.)
· Attachments, signatures etc.
 
The resulting model, even if it referenced other objects, would be
unmanageable. What is required is the ability to break the application down into its constituent elements. 

One way in which we could do this would be to have separate
parts of the architecture deal with the address book, the sender element,reading mail, creating mail etc. This is where the hierarchical MVC comes in.

The H-MVC

The Hierarchical MVC framework (referred to in this column as h-MVC) is a modification of the basic MVC framework that encourages the decomposition of an application, or client, in an n-tier architecture. It is of course not the only way in which such a GUI oriented application (or client) can be decomposed, but some of the benefits of this approach include.

· Building on a well established existing framework (the MVC)
· Standardizing structures and interactions between different aspects of the application – leading to greater understanding between developers.
· Simplifying code maintenance code as each aspect can be developed,modified or updated separately.

The H-MVC Details

The hierarchical MVC (h-MVC) breaks the client part of an application whether a stand alone application or part of an n-tier system) down into separate MVC triads. 

Each MVC is then responsible for one aspect of the client.
Between the MVCs, well defined interfaces exist to allow information and behaviour-oriented requests to flow. These interfaces are supported by links between the controllers. 

The rationale behind this is that the controllers are
responsible for determining the flow-of-control within an MVC triad.Therefore, if one MVC triad needs to communicate with another MVC triad,then it is the controllers that should be responsible for this. 

This in turn meansthat the links between one MVC triad and another will necessarily be maintained by the controllers.

In this view we are applying OO principles to the design and implementation of the client. 

That is each MVC triad has :
· A particular responsibility
· Clearly defined interfaces to other MVC’s


Layered Application
 
The following (simple) example application will be used to illustrate the ideas behind the h-MVC. This application allows a user to input some simple search criteria in the name, age and sex fields. These can then run the search, the results of which are presented in the search results view. 
 

 
 Figure 2: The Search Application

The application is actually constructed using 3 MVC triads. The first triad represents the overall frame, the second triad deals with the search criteria,while the third triad deals with presenting the results of the search. This is illustrated in figure 3.




Figure 3: The MVC structure of the Search Application


The hierarchy represented by the links between the controllers in the three MVC triads is illustrated in figure 4.




Figure 4: The classes in the search application



Figure 6: The relationships between the search application classes and the MVC framework classes

MVC - pattern : a must to keep in mind

Model/view/controller (MVC) is a software architecture, currently considered an architectural pattern, used in software engineering. 

The pattern isolates "domain logic" (the application logic for the user) from the user interface (input and presentation), permitting independent development, testing and maintenance of each (separation of concerns).

Use of the Model/View/Controller (MVC) pattern results in applications that separate the different aspects of the application (input logic, business logic, and UI logic), while providing a loose coupling between these elements.

Though MVC comes in different flavors, control flow is generally as follows:

1. The user interacts with the user interface in some way (for example, by pressing a mouse button).
2. The controller handles the input event from the user interface, often via a registered handler or callback, and converts the event into an appropriate user action, understandable for the model.
3. The controller notifies the model of the user action, possibly resulting in a change in the model's state. (For example, the controller updates the user's shopping cart)
4. A view queries the model in order to generate an appropriate user interface (for example the view lists the shopping cart's contents). The view gets its own data from the model. In some implementations, the controller may issue a general instruction to the view to render itself. In others, the view is automatically notified by the model of changes in state (Observer) that require a screen update.
5. The user interface waits for further user interactions, which restarts the control flow cycle.

The model manages the behavior and data of the application domain, responds to requests for information about its state (usually from the view), and responds to instructions to change state (usually from the controller). In event-driven systems, the model notifies observers (usually views) when the information changes so that they can react.

The view renders the model into a form suitable for interaction, typically a user interface element. Multiple views can exist for a single model for different purposes. A view port typically has a one to one correspondence with a display surface and knows how to render to it.

The controller receives user input and initiates a response by making calls on model objects. A controller accepts input from the user and instructs the model and a view port to perform actions based on that input.