我的程序人生

http://wiki.jboss.org/wiki/JBossASTuningSliming

Preface

This advice is primarily on how to tune and/or slim JBossAS. The two concepts are orthogonal in most cases. While reducing idle service threads through slimming won't have a large impact on performance, using less memory and resources may allow you to tune other performance aspects. Of course this does reduce startup time. Furthermore, as a general security concept -- remove services you don't use. We will separate the two categories: slimming and tuning. We start by using the default configuration and trimming from there (for clustering that will be the topic of a later wiki page ;-) ). This advice does not involve areas of tuning that crosscut developer and administrative roles (application tuning such as cache sizes). This is primarily advice for administrative tuning.

Note for those concerned that this advice will make a technically non-J2EE-compliant instance of JBoss (3.2.6 is not compliant anyhow) as removing key J2EE services would cause JBoss to fail the TCK. Most performance tuning/administrative tasks done in real-world installations technically fall in this category.

Assume that you have copied the server/default directory and its subdirectories to server/slim.

Tuning

Java Virtual Machine

• TuneVMGarbageCollection or Tune JDK 5 Garbage Collection for your machine and memory size
• Use a 64 bit machine and 64 bit VM so that you can use large heap sizes, larger than 2-4GB typically. 64 bit support is available on all recent SPARC/Solaris boxes running Solaris 9 or later, Itanium with JDK 1.4, or JDK 5 on Linux x64.
• DO NOT USE -d64 (64-bit) if you do not use ABOVE the maximum 32 bit heap space (2-4 GB of heap). Using 64 bit addressing requires MORE memory to do the same amount of work and provides no advantage for applications that do not need this much memory.
• Avoid extra large heaps but avoid extra small heaps. (We cannot tell you what qualifies because it depends on what you're doing). This affects generational garbage collection and total time to scan the heap. It is difficult to tune a small heap effectively (even if your app only uses 200MB, if you're using parallel garbage collection + CMS, then you're going to need well above 512MB). Oversize heaps spend needless time scanning memory for garbage collection.
• Avoid the Sun 1.4 VM. JDK 5 is VASTLY better especially in the area of garbage collection.
• Use the -server option but use either of -XX:ThreadStackSize?=128k (Solaris) or -Xss128k (every other platform). On Solaris -Xss128k does nothing (you can only set LARGER thread stack sizes). This allows you to create more threads by using less memory per thread but might result in blown stacks with extremely recursive code. Still, 128k stack is still nothing to shake a stick at.
• You really need to understand generational garbage collectors to tune this properly and you really have to do load testing (OpenSTA?, JMeter, etc) to know for sure.
• You really should use a multi-processor machine with more than 2 processors and use various parallel and concurrent garbage collection options (we cover this in Advanced JBoss Training hint hint) for maximum performance and high garbage collector throughput. However, you really need to understand how garbage collection works to tune this well. JDK 5 is mostly self-tuning.
• JDK 1.4's default NewSize is not a good guess. Bad rule of thumb: < 20% is a good NewSize. Above 20% is dangerous due to a nasty JDK bug which can cause it to psychotically run all full garbage collections and never unsuspend or free up enough memory. JDK 5 does not seem to exhibit this bug and seems to pick more sane defaults.

JBoss/Java on Linux

If you are running JBoss AS on a Linux server, you should read this article written by Andrew Oliver, one of JBoss, a division of Red Hat, consultants on how tune JBoss/Java in a Linux server

Tomcat

• Edit your server/slim/jbossweb-tomcat5?.sar/server.xml
• Check the XML document for connectors you are using. For example, the HTTP connector:

<Connector port="8080" address="${jboss.bind.address}"
maxThreads="150" minSpareThreads="25" maxSpareThreads="75"
enableLookups="false" redirectPort="8443" acceptCount="100"
connectionTimeout="20000" disableUploadTimeout="true"/>

• You should have enough threads (maxThreads) to handle (rule of thumb) 25% more than your maximum expected load (concurrent hits coming in at once)
• You should have minSpareThreads equal just a little more than your normal load
• You should have maxSpareThreads equal just a little more than your peak load

• minSpareThreads

  means "on start up, always keep at least this many threads waiting idle"

• maxSpareThreads

  means "if we ever go above minSpareThreads then always keep maxSpareThreads waiting idle"

• Remove any unnecessary valves and logging. If you're not using JBoss's security, remove the security valve (see below).
• Precompile JSPs. (The built-in compiler is fairly fast, it may not be worthwhile for small sites.)
• Turn off "development" mode in you sever/slim/jbossweb-tomcat50.sar/conf/web.xml

RMI for Remote Invocations

By default, JBoss creates a new thread for every RMI request that comes in. This is not generally efficient on a large system. Secondly, it can be dangerous to allow unrestrained connections in the case of performance or traffic spikes or run-away connection creating clients. To remedy this you should consider switching to the pooled invoker.

• Edit server/slim/conf/standardjboss.xml
• Change all of the proxy bindings to the pooled invoker by changing every XML fragment reading:

<invoker-mbean>jboss:service=invoker,type=jrmp</invoker-mbean>

to

<invoker-mbean>jboss:service=invoker,type=pooled</invoker-mbean>

JBoss also has a mostly undocumented PooledInvokerHA you may try.

Log4j

Logging has a profound effect on performance. Changing the logging level to TRACE can bring the JBossAS to a crawl. Changing it to ERROR (or WARN) can speed things up dramatically.

• By default, JBoss logs both to the console and server.log and by default it uses level "INFO".
• Consider not logging to System.out (you may still want to redirect it to catch JVM errors)
• Consider changing the log level to ERROR. Remember that JBoss watches its log4j config file for changes and you can always change configuration at runtime.
• Add a category filter for your Java class hierarchy.

To turn off console logging:

• Edit server/slim/conf/log4j.xml
• Change the following XML fragment:

<root>
<appender-ref ref=CONSOLE"/>
<appender-ref ref="FILE"/>
</root>

make it read

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

• You can then remove this fragment:

<appender name="CONSOLE" class="org.apache.log4j.ConsoleAppender">
<errorHandler class="org.jboss.logging.util.OnlyOnceErrorHandler"/>
<param name="Target" value="System.out"/>
<param name="Threshold" value="INFO"/>
<layout class="org.apache.log4j.PatternLayout">
<!-- The default pattern: Date Priority [Category] Message\n -->
<param name="ConversionPattern" value="%d{ABSOLUTE} %-5p [%c{1}] %m%n"/>
</layout>
</appender>

To change the log level:

• Edit server/slim/conf/log4j.xml
• Remove/comment these XML fragments:

<category name="org.apache">
<priority value="INFO"/>
</category>
<!-- Limit org.jgroups category to INFO -->
<category name="org.jgroups">
<priority value="INFO"/>
</category>

• Change the root category by changing this XML fragment:

<root>
<appender-ref ref="CONSOLE"/> <!-- you may have removed this earlier -->
<appender-ref ref="FILE"/>
</root>

to look like this

<root>
<priority value="ERROR" />
<appender-ref ref="CONSOLE"/> <!-- you may have removed this earlier -->
<appender-ref ref="FILE"/>
</root>

And finally, probably the most important thing in log4j, make sure you limit the logging level on your own class hierarchy. This assumes that you are using log4j as it was intended and not writing everything to System.out. This will significantly reduce the overhead of log4j and allow you to fully enjoy the benefits of calls like

if (log.isDebugEnabled())...

. If you don't do this then all the logging in your code will get formatted and passed to the appender, and the threshold on the appender will weed out the log messages. This can generate a significant amount of garbage. Assuming your java package starts with "a.b", add something like this to log4j.xml:

<!-- Limit a.b category to INFO -->
<category name="a.b">
<priority value="INFO"/>
</category>

This can be added in the same area where you find the category filters for org.apache and org.jboss (see above).

Deployment Scanner

• The deployment scanner scanning every 5 seconds eats up cycles especially on systems with a slow filesystem (*cough* NTFS *cough*).
• See the below slimming stuff on how to turn the number of seconds such that it happens less frequently or not at all

Stateless Session Beans

• EJB 1.x-2.x stateless session beans operate with an ill-advised pooling model (required by the specification). If you find that you need more than the default (10) instances consider setting the minimum pool size:

edit

server/slim/conf/standardjboss.xml

, scroll down to:

<container-configuration>
<container-name>Standard Stateless SessionBean</container-name>
<call-logging>false</call-logging>
<invoker-proxy-binding-name>stateless-rmi-invoker</invoker-proxy-binding-name>
<container-interceptors>

and find:

<container-pool-conf>
<MaximumSize>100</MaximumSize>
</container-pool-conf>
</container-configuration>

change it to read:

<container-pool-conf>
<MinimumSize>100</MinimumSize>
<MaximumSize>100</MaximumSize>
<strictMaximumSize/>
<strictTimeout>30000</strictTimeout>
</container-pool-conf>
</container-configuration>

For the most part a server environment doesn't want these pools growing and shrinking (because it causes memory-fragmentation and thats worse than latent heap usage). From a performance standpoint, the nuber should be big enough to serve all your requests with no blocking.

CMP tuning

• Read this: http://www.artima.com/forums/flat.jsp?forum=141&thread=24532
• and this: http://www.onjava.com/pub/a/onjava/2003/05/28/jboss_optimization.html
• now ditch CMP and use JBossHibernate instead

Connection Pools

• Don't use XA versions unless you really know you need them. XA connections do not have good performance.
• Use database specific "ping" support where available for "check-connection" or use database-specific driver fail-over support rather than checking connections at all. (remember that not all tuning options may be feasible in your environment, we're talking optimal)

Slimming

When not using the mail-service (J2EE standard JavaMail client)

• remove server/slim/deploy/mail-service.xml
• remove server/slim/lib/mail* (mail-plugin.jar, mail.jar - JavaMail stuff)
• remove server/slim/lib/activation.jar (Java Activation Framework is used by JavaMail)

When not using the cache invalidation service (used for CMP Option A beans with Cache Invalidation usually in a clustered configuration)

• remove server/slim/deloy/cache-invalidation-service.xml

When not using the J2EE client deployer service (this is a not very useful J2EE spec required service for the EAR application-client.xml descriptor)

• remove server/slim/deploy/client-deployer-service.xml

When not using the integrated HAR deployer and Hibernate session management services

• remove server/slim/deploy/hibernate-deployer-service.xml (HAR support)
• remove server/slim/lib/jboss-hibernate.jar (HAR support)
• remove server/slim/lib/hibernate2.jar (Hibernate itself)
• remove server/slim/lib/cglib-full-2.0.1.jar (used by Hibernate to create proxies of POJOs)
• remove server/slim/lib/odmg-3.0.jar (some goofy object-relational mapping thing used by hibernate from some goofy committee http://www.service-architecture.com/database/articles/odmg_3_0.html)

When not using Hypersonic (which you should not in production)

Note that JBossMQ as deployed in the default configuration uses DefaultDS with mappings for Hypersonic. See JBoss MQ Persistence Wiki pages for more information on configuring other alternatives.

• remove server/slim/deploy/hsqldb-ds.xml
• remove server/slim/lib/hsqldb-plugin.jar
• remove server/slim/lib/hsqldb.jar

When not using JBossMQ (our JMS server)

• remove the entire server/slim/deploy/jms directory
• remove server/slim/lib/jbossmq.jar

When not using the HTTPInvoker (which lets you tunnel RMI over HTTP)

• remove the entire server/slim/deploy/http-invoker.sar directory

When not using XA datasources (Distributed and/or recoverable transactions)

• remove server/slim/deploy/jboss-xa-jdbc.rar

If you do not need the JMX-Console then remove it

• remove server/slim/deploy/jmx-console.war
• Otherwise Secure it

If you do not need to make JMX calls over RMI (warning the shutdown.sh DOES do this)

• remove server/slim/deploy/jmx-invoker-adaptor-server.sar
• remove server/slim/deploy/jmx-adaptor-plugin.jar
• or you may want to just secure the JMX invoker-adaptor instead

If you do not need the web-console

• remove server/slim/deploy/management/web-console.war

If you do not need JSR-77 extensions for JMX

• remove server/slim/deploy/management/console-mgr.sar

If you need neither the web-console or jsr-77 extensions

• remove server/slim/deploy/management directory entirely

If you are not using console/email monitor alerts

• remove server/slim/deploy/monitoring-service.xml
• remove server/slim/lib/jboss-monitoring.jar

If you are not using rich property editors (JMX) or loading properties into system properties via the Properties Service

• remove server/slim/deploy/properties-service.xml
• remove server/slim/lib/properties-plugin.jar

The scheduler-service.xml is an example unless you have put your own in it

• remove server/slim/deploy/scheduler-service.xml

If you are not using the JBoss Scheduler Manager (allows you to schedule invocations against MBeans)

• remove server/slim/deploy/schedule-manager-service.xml
• remove server/slim/lib/scheduler-plugin* (scheduler-plugin.jar, scheduler-plugin-example.jar)

If you do not need vendor-specific sql exception handing (just leave it, really)

• remove server/slim/deploy/sqlexception-service.xml

If you are using neither client-side transaction management nor cached connections (where instead of pooling we cache connections such as in the case of JAAS->DB User -- using this means you are a bad person and need to be smacked)

• remove server/slim/deploy/user-service.xml

If you do not use JBoss UUID key generation (often used with CMP primary keys, but we have database specific support as well)

• remove server/slim/deploy/uuid-key-generator.sar
• remove server/slim/lib/autonumber-plugin.jar

user-service.xml is an example -- unless you put something in it (your own mbeans) you can always remove it.

• remove server/slim/deploy/user-service.xml

If your users directly connect to Tomcat via HTTP and do not pass through Apache/mod_jk:

• open server/slim/deploy/jbossweb-tomcat50.sar/server.xml in the vi editor
• remove/comment the following XML fragment:

<!-- A AJP 1.3 Connector on port 8009 -->
<Connector port="8009" address="${jboss.bind.address}"
enableLookups="false" redirectPort="8443" debug="0"
protocol="AJP/1.3"/>

If your users do not directly connect to Tomcat via HTTP and always pass through Apache/mod_jk

• open server/slim/deploy/jbossweb-tomcat50.sar/server.xml in the vi editor
• remove/comment the following XML fragment:

<!-- A HTTP/1.1 Connector on port 8080 -->
<Connector port="8080" address="${jboss.bind.address}"
maxThreads="150" minSpareThreads="25" maxSpareThreads="75"
enableLookups="false" redirectPort="8443" acceptCount="100"
connectionTimeout="20000" disableUploadTimeout="true"/>

If you do not need to be able to deploy EAR files

• open server/slim/conf/jboss-service.xml in the vi editor
• remove/comment the following XML fragments from the

from under the

<mbean code="org.jboss.management.j2ee.LocalJBossServerDomain"

MBean

<attribute name="EARDeployer">jboss.j2ee:service=EARDeployer</attribute>

and

<!-- EAR deployer, remove if you are not using Web layers -->
<mbean code="org.jboss.deployment.EARDeployer" name="jboss.j2ee:service=EARDeployer">
</mbean>

If you do not need to be able to deploy JMS Queues

• open server/slim/conf/jboss-service.xml in the vi editor
• remove/comment the following XML fragments from the

from under the

<mbean code="org.jboss.management.j2ee.LocalJBossServerDomain"

MBean

<attribute name="JMSService">jboss.mq:service=DestinationManager</attribute>

If you do not need to use CORBA/IIOP

• open server/slim/conf/jboss-service.xml in the vi editor
• remove/comment the following XML fragments from the

from under the

<mbean code="org.jboss.management.j2ee.LocalJBossServerDomain"

MBean

<attribute name="RMI_IIOPService">jboss:service=CorbaORB</attribute>

If you removed the user-transaction-service.xml

• open server/slim/conf/jboss-service.xml in the vi editor
• remove/comment the following XML fragments from the

from under the

<mbean code="org.jboss.management.j2ee.LocalJBossServerDomain"

MBean

<attribute name="UserTransactionService">jboss:service=ClientUserTransaction</attribute>

If you do not need JSR-77 support (tried to make JBoss, Weblogic and Websphere support some basic similar JMX monitoring) you can remove/comment the entire fragment from server/slim/conf/jboss-service.xml:

<!-- ==================================================================== -->
<!-- JSR-77 Single JBoss Server Management Domain -->
<!-- ==================================================================== -->
<mbean code="org.jboss.management.j2ee.LocalJBossServerDomain"
name="jboss.management.local:j2eeType=J2EEDomain,name=Manager">
<attribute name="MainDeployer">jboss.system:service=MainDeployer</attribute>
<attribute name="SARDeployer">jboss.system:service=ServiceDeployer</attribute>
<!-- <attribute name="EARDeployer">jboss.j2ee:service=EARDeployer</attribute>-->
<attribute name="EJBDeployer">jboss.ejb:service=EJBDeployer</attribute>
<attribute name="RARDeployer">jboss.jca:service=RARDeployer</attribute>
<attribute name="CMDeployer">jboss.jca:service=ConnectionFactoryDeployer</attribute>
<attribute name="WARDeployer">jboss.web:service=WebServer</attribute>
<attribute name="MailService">jboss:service=Mail</attribute>
<!-- <attribute name="JMSService">jboss.mq:service=DestinationManager</attribute>-->
<attribute name="JNDIService">jboss:service=Naming</attribute>
<attribute name="JTAService">jboss:service=TransactionManager</attribute>
<!-- <attribute name="UserTransactionService">jboss:service=ClientUserTransaction</attribute>
<attribute name="RMI_IIOPService">jboss:service=CorbaORB</attribute>-->
</mbean>

If you do not need client-side transaction management (remember that using this means you're a bad person)

• open server/slim/conf/jboss-service.xml in the vi editor
• remove/comment the following XML fragments

<!--
| UserTransaction support.
-->
<mbean code="org.jboss.tm.usertx.server.ClientUserTransactionService"
name="jboss:service=ClientUserTransaction"
xmbean-dd="resource:xmdesc/ClientUserTransaction-xmbean.xml">
<depends>
<mbean code="org.jboss.invocation.jrmp.server.JRMPProxyFactory"
name="jboss:service=proxyFactory,target=ClientUserTransactionFactory">
<attribute name="InvokerName">jboss:service=invoker,type=jrmp</attribute>
<attribute name="TargetName">jboss:service=ClientUserTransaction</attribute>
<attribute name="JndiName">UserTransactionSessionFactory</attribute>
<attribute name="ExportedInterface">
org.jboss.tm.usertx.interfaces.UserTransactionSessionFactory
</attribute>
<attribute name="ClientInterceptors">
<interceptors>
<interceptor>org.jboss.proxy.ClientMethodInterceptor</interceptor>
<interceptor>org.jboss.invocation.InvokerInterceptor</interceptor>
</interceptors>
</attribute>
<depends>jboss:service=invoker,type=jrmp</depends>
</mbean>
</depends>
<depends optional-attribute-name="TxProxyName">
<mbean code="org.jboss.invocation.jrmp.server.JRMPProxyFactory"
name="jboss:service=proxyFactory,target=ClientUserTransaction">
<attribute name="InvokerName">jboss:service=invoker,type=jrmp</attribute>
<attribute name="TargetName">jboss:service=ClientUserTransaction</attribute>
<attribute name="JndiName"></attribute>
<attribute name="ExportedInterface">
org.jboss.tm.usertx.interfaces.UserTransactionSession
</attribute>
<attribute name="ClientInterceptors">
<interceptors>
<interceptor>org.jboss.proxy.ClientMethodInterceptor</interceptor>
<interceptor>org.jboss.invocation.InvokerInterceptor</interceptor>
</interceptors>
</attribute>
<depends>jboss:service=invoker,type=jrmp</depends>
</mbean>
</depends>
</mbean>

• you can now remove server/slim/conf/xmdesc/ClientUserTransaction-xmbean.xml since its not referenced

if you do not need persistent MBean attributes (no JBoss MBeans use this by default...yet)

• open server/slim/conf/jboss-service.xml in the vi editor
• remove/comment this XML fragment

<!-- ==================================================================== -->
<!-- XMBean Persistence -->
<!-- ==================================================================== -->
<mbean code="org.jboss.system.pm.AttributePersistenceService"
name="jboss:service=AttributePersistenceService"
xmbean-dd="resource:xmdesc/AttributePersistenceService-xmbean.xml">
<attribute name="AttributePersistenceManagerClass">
org.jboss.system.pm.XMLAttributePersistenceManager
</attribute>
<attribute name="AttributePersistenceManagerConfig">
<data-directory>data/xmbean-attrs</data-directory>
</attribute>
<attribute name="ApmDestroyOnServiceStop">false</attribute>
<attribute name="VersionTag"></attribute>
</mbean>

• you can also remove server/slim/conf/xmdec/xmdesc/AttributePersistenceService-xmbean.xml since it is no longer referenced

If you do not use RMI Classloading (for loading codebases from the client using the classes on the server)

• open server/slim/conf/jboss-service.xml in the vi editor
• remove/comment this XML fragment

<!-- ==================================================================== -->
<!-- JBoss RMI Classloader - only install when available -->
<!-- ==================================================================== -->
<mbean code="org.jboss.util.property.jmx.SystemPropertyClassValue"
name="jboss.rmi:type=RMIClassLoader">
<attribute name="Property">java.rmi.server.RMIClassLoaderSpi</attribute>
<attribute name="ClassName">org.jboss.system.JBossRMIClassLoader</attribute>
</mbean>

and

<!-- ==================================================================== -->
<!-- Class Loading -->
<!-- ==================================================================== -->
<mbean code="org.jboss.web.WebService"
name="jboss:service=WebService">
<attribute name="Port">8083</attribute>
<!-- Should resources and non-EJB classes be downloadable -->
<attribute name="DownloadServerClasses">true</attribute>
<attribute name="Host">${jboss.bind.address}</attribute>
<attribute name="BindAddress">${jboss.bind.address}</attribute>
</mbean>

• and change this XML fragment (NOTE: In JBoss 4.0, this is located in the file server/slim/deploy/ejb-deployer.xml):

<!-- EJB deployer, remove to disable EJB behavior-->
<mbean code="org.jboss.ejb.EJBDeployer" name="jboss.ejb:service=EJBDeployer">
<attribute name="VerifyDeployments">true</attribute>
...
<depends optional-attribute-name="WebServiceName">jboss:service=WebService</depends>
</mbean>

to read like this:

<!-- EJB deployer, remove to disable EJB behavior-->
<mbean code="org.jboss.ejb.EJBDeployer" name="jboss.ejb:service=EJBDeployer">
<attribute name="VerifyDeployments">true</attribute>
...
<!-- <depends optional-attribute-name="WebServiceName">jboss:service=WebService</depends> -->
</mbean>

or alternatively remove the WebServiceName? depends/attribute.

If you only want to use JBoss Naming locally (no RMI clients)

• open server/slim/conf/jboss-service.xml in vi
• change the following XML fragment

<!-- ==================================================================== -->
<!-- JNDI -->
<!-- ==================================================================== -->
<mbean code="org.jboss.naming.NamingService"
name="jboss:service=Naming"
xmbean-dd="resource:xmdesc/NamingService-xmbean.xml">
...
<!-- The listening port for the bootstrap JNP service. Set this to -1
to run the NamingService without the JNP invoker listening port.
-->
<attribute name="Port">1099</attribute>
...
<!-- The port of the RMI naming service, 0 == anonymous -->
<attribute name="RmiPort">1098</attribute>
...
</mbean>

To read

<!-- ==================================================================== -->
<!-- JNDI -->
<!-- ==================================================================== -->
<mbean code="org.jboss.naming.NamingService"
name="jboss:service=Naming"
xmbean-dd="resource:xmdesc/NamingService-xmbean.xml">
...
<!-- The listening port for the bootstrap JNP service. Set this to -1
to run the NamingService without the JNP invoker listening port.
-->
<attribute name="Port">-1</attribute>
...
<!-- The port of the RMI naming service, 0 == anonymous -->
<attribute name="RmiPort">0</attribute>
...
</mbean>

The RmiPort is mostly optional but it means we won't bind to 1098 so that can be helpful.

You may also want to remove the thread pool associated by removing this line from the same XML block:

<depends optional-attribute-name="LookupPool"
proxy-type="attribute">jboss.system:service=ThreadPool</depends>

and the thread pool block itself:

<!-- A Thread pool service -->
<mbean code="org.jboss.util.threadpool.BasicThreadPool"
name="jboss.system:service=ThreadPool">
<attribute name="Name">JBoss System Threads</attribute>
<attribute name="ThreadGroupName">System Threads</attribute>
<attribute name="KeepAliveTime">60000</attribute>
<attribute name="MinimumPoolSize">1</attribute>
<attribute name="MaximumPoolSize">10</attribute>
<attribute name="MaximumQueueSize">1000</attribute>
<attribute name="BlockingMode">run</attribute>
</mbean>

The JNDIView MBean (shows the JNDI naming tree) is increadibly useful from the JMX Console if you want to use it, but if you don't

• open server/slim/conf/jboss-service.xml in vi
• remove

<mbean code="org.jboss.naming.JNDIView"
name="jboss:service=JNDIView"
xmbean-dd="resource:xmdesc/JNDIView-xmbean.xml">
</mbean>

• you can also remove server/slim/conf/xmdesc/JNDIView-xmbean.xml

If you do not use JBossSX, our integrated JAAS-based security for EJBs or Web-tier components (then you deserve to be flogged and I hope you get hacked but thats another story):

• open server/slim/conf/jboss-service.xml in vi
• remove

<!-- ==================================================================== -->
<!-- Security -->
<!-- ==================================================================== -->
<!--
<mbean code="org.jboss.security.plugins.SecurityConfig"
name="jboss.security:service=SecurityConfig">
<attribute name="LoginConfig">jboss.security:service=XMLLoginConfig</attribute>
</mbean>
<mbean code="org.jboss.security.auth.login.XMLLoginConfig"
name="jboss.security:service=XMLLoginConfig">
<attribute name="ConfigResource">login-config.xml</attribute>
</mbean>

• edit server/slim/deploy/jbossweb-tomcatxx.sar/META-INF/jboss-service.xml and comment out these fragments:

<!-- The JAAS security domain to use in the absense of an explicit
security-domain specification in the war WEB-INF/jboss-web.xml
-->
<!-- <attribute name="DefaultSecurityDomain">java:/jaas/other</attribute>-->

and

<!-- A mapping to the server security manager service which must be
operation compatible with type
org.jboss.security.plugins.JaasSecurityManagerServiceMBean. This is only
needed if web applications are allowed to flush the security manager
authentication cache when the web sessions invalidate.
-->
<!-- <depends optional-attribute-name="SecurityManagerService"
proxy-type="attribute">jboss.security:service=JaasSecurityManager
</depends>-->

• also remove/comment:

<!-- JAAS security manager and realm mapping --> <mbean code="org.jboss.security.plugins.JaasSecurityManagerService"
name="jboss.security:service=JaasSecurityManager">
<attribute name="SecurityManagerClassName">
org.jboss.security.plugins.JaasSecurityManager
</attribute>
<attribute name="DefaultCacheTimeout">1800</attribute>
<attribute name="DefaultCacheResolution">60</attribute>
</mbean>

• If you're using JBossMQ you'll need to either remove (preferred) all test queues/topics from server/slim/deploy/jms/jbossmq-destinations-service.xml or comment out their security information. Add comments like the following if you choose to keep the example topics/queues:

<mbean code="org.jboss.mq.server.jmx.Topic"
name="jboss.mq.destination:service=Topic,name=testTopic">
<depends optional-attribute-name="DestinationManager">jboss.mq:service=DestinationManager</depends>
<!-- <depends optional-attribute-name="SecurityManager">jboss.mq:service=SecurityManager</depends>
<attribute name="SecurityConf">
<security>
<role name="guest" read="true" write="true"/>
<role name="publisher" read="true" write="true" create="false"/>
<role name="durpublisher" read="true" write="true" create="true"/>
</security>
</attribute>-->
</mbean>
<mbean code="org.jboss.mq.server.jmx.Topic"
name="jboss.mq.destination:service=Topic,name=testTopic">
<depends optional-attribute-name="DestinationManager">jboss.mq:service=DestinationManager</depends>
<!-- <depends optional-attribute-name="SecurityManager">jboss.mq:service=SecurityManager</depends>
<attribute name="SecurityConf">
<security>
<role name="guest" read="true" write="true"/>
<role name="publisher" read="true" write="true" create="false"/>
<role name="durpublisher" read="true" write="true" create="true"/>
</security>
</attribute>-->
</mbean>
<mbean code="org.jboss.mq.server.jmx.Topic"
name="jboss.mq.destination:service=Topic,name=testDurableTopic">
<depends optional-attribute-name="DestinationManager">jboss.mq:service=DestinationManager</depends>
<!--
<depends optional-attribute-name="SecurityManager">jboss.mq:service=SecurityManager</depends>
<attribute name="SecurityConf">
<security>
<role name="guest" read="true" write="true"/>
<role name="publisher" read="true" write="true" create="false"/>
<role name="durpublisher" read="true" write="true" create="true"/>
</security>
</attribute>-->
</mbean>
<mbean code="org.jboss.mq.server.jmx.Queue"
name="jboss.mq.destination:service=Queue,name=testQueue">
<depends optional-attribute-name="DestinationManager">jboss.mq:service=DestinationManager</depends>
<!--
<depends optional-attribute-name="SecurityManager">jboss.mq:service=SecurityManager</depends>
<attribute name="SecurityConf">
<security>
<role name="guest" read="true" write="true"/>
<role name="publisher" read="true" write="true" create="false"/>
<role name="noacc" read="false" write="false" create="false"/>
</security>
</attribute>-->
</mbean>

• if using JBossMQ you'll also need to edit server/slim/deploy/jms/jbossmq-service.xml and change the InterceptorLoader? XML fragment to read like this:

<mbean code="org.jboss.mq.server.jmx.InterceptorLoader" name="jboss.mq:service=TracingInterceptor">
<attribute name="InterceptorClass">org.jboss.mq.server.TracingInterceptor</attribute>
<depends optional-attribute-name="NextInterceptor">jboss.mq:service=DestinationManager</depends>
<!--
<depends optional-attribute-name="NextInterceptor">jboss.mq:service=SecurityManager</depends>
-->
</mbean>

• you'll also need to comment out or remove (from server/slim/deploy/jms/jbossmq-service.xml):

<!-- <mbean code="org.jboss.mq.security.SecurityManager" name="jboss.mq:service=SecurityManager">
<attribute name="DefaultSecurityConfig">
<security>
<role name="guest" read="true" write="true" create="true"/>
</security>
</attribute>
<attribute name="SecurityDomain">java:/jaas/jbossmq</attribute>
<depends optional-attribute-name="NextInterceptor">jboss.mq:service=DestinationManager</depends>
</mbean>
-->

• alter the dead letter queue entry (server/slim/deploy/jms/jbossmq-service.xml) by commenting out the security stuff:

<!-- Dead Letter Queue -->
<mbean code="org.jboss.mq.server.jmx.Queue"
name="jboss.mq.destination:service=Queue,name=DLQ">
<depends optional-attribute-name="DestinationManager">jboss.mq:service=DestinationManager</depends>
<!--
<depends optional-attribute-name="SecurityManager">jboss.mq:service=SecurityManager</depends>-->
</mbean>

• in server/slim/deploy/jms/jms-ds.xml alter the JmsXA entry to read as follows:

<!-- JMS XA Resource adapter, use this to get transacted JMS in beans -->
<tx-connection-factory>
<jndi-name>JmsXA</jndi-name>
<xa-transaction/>
<adapter-display-name>JMS Adapter</adapter-display-name>
<config-property name="SessionDefaultType" type="java.lang.String">javax.jms.Topic</config-property>
<config-property name="JmsProviderAdapterJNDI" type="java.lang.String">java:/DefaultJMSProvider</config-property>
<max-pool-size>20</max-pool-size>
<!--
<security-domain-and-application>JmsXARealm</security-domain-and-application>-->
</tx-connection-factory>

• If using JBoss 4, also do this 2 things:
• in conf/login-config.xml, comment as follows:

<!-- Security domains for testing new jca framework
<application-policy name = "HsqlDbRealm">
<authentication>
<login-module code = "org.jboss.resource.security.ConfiguredIdentityLoginModule"
flag = "required">
<module-option name = "principal">sa</module-option>
<module-option name = "userName">sa</module-option>
<module-option name = "password"></module-option>
<module-option name = "managedConnectionFactoryName">
jboss.jca:service=LocalTxCM,name=DefaultDS
</module-option>
</login-module>
</authentication>
</application-policy>
<application-policy name = "JmsXARealm">
<authentication>
<login-module code = "org.jboss.resource.security.ConfiguredIdentityLoginModule"
flag = "required">
<module-option name = "principal">guest</module-option>
<module-option name = "userName">guest</module-option>
<module-option name = "password">guest</module-option>
<module-option name = "managedConnectionFactoryName">
jboss.jca:service=TxCM,name=JmsXA
</module-option>
</login-module>
</authentication>
</application-policy> -->

• and in deploy/hsqldb-ds.xml comment:

<!-- Use the security domain defined in conf/login-config.xml
<security-domain>HsqlDbRealm</security-domain> -->

If you are not using the Pooled Invoker (see tuning section, you may want to use the pooled invoker) then:

• open server/slim/conf/jboss-service.xml in vi
• remove:

<!--
<mbean code="org.jboss.invocation.pooled.server.PooledInvoker"
name="jboss:service=invoker,type=pooled">
<attribute name="NumAcceptThreads">1</attribute>
<attribute name="MaxPoolSize">300</attribute>
<attribute name="ClientMaxPoolSize">300</attribute>
<attribute name="SocketTimeout">60000</attribute>
<attribute name="ServerBindAddress">${jboss.bind.address}</attribute>
<attribute name="ServerBindPort">4445</attribute>
<attribute name="ClientConnectAddress">${jboss.bind.address}</attribute>
<attribute name="ClientConnectPort">0</attribute>
<attribute name="EnableTcpNoDelay">false</attribute>
<depends optional-attribute-name="TransactionManagerService">
jboss:service=TransactionManager</depends>
</mbean>

If you do not wish to use the BeanShell deployer

• open server/slim/conf/jboss-service.xml in vi
• remove or comment

<mbean code="org.jboss.varia.deployment.BeanShellSubDeployer"
name="jboss.scripts:service=BSHDeployer">
</mbean>

• remove server/slim/bsh* (bsh-deployer.jar, bsh-1.3.0.jar)

If you do not hot deploy files into the server/slim/deploy directory without restarting JBoss:

• open server/slim/conf/jboss-service.xml in vi
• change this XML frament:

<!-- An mbean for hot deployment/undeployment of archives.
-->
<mbean code="org.jboss.deployment.scanner.URLDeploymentScanner"
name="jboss.deployment:type=DeploymentScanner,flavor=URL">
...
<attribute name="ScanPeriod">5000</attribute>
...
</mbean>

to read (by adding):

<!-- An mbean for hot deployment/undeployment of archives.
-->
<mbean code="org.jboss.deployment.scanner.URLDeploymentScanner"
name="jboss.deployment:type=DeploymentScanner,flavor=URL">
...
<attribute name="ScanPeriod">5000</attribute>
<attribute name="ScanEnabled">False</attribute>
...
</mbean>

• see the tuning section for other advice regarding this from a performance perspective

If you do not use clustering

• The best way to do this is to start from the "default" config rather than the "all" config. Then bring over from the "all" config any miscellaneous services that you are using that aren't in "default".
• If you must to start from the "all" config:
  • Remove server/slim/farm
  • Remove server/slim/deploy-hasingleton
  • Remove server/slim/deploy/cluster-service.xml
  • Remove server/slim/deploy/tc5-cluster-service.xml (OR server/slim/deploy/tc5-cluster.sar on 4.0.4 or later)
  • Remove server/slim/deploy/deploy.last/farm-service.xml
  • Remove server/slim/deploy/deploy-hasingleton-service.xml
  • Go into the server/slim/deploy/jms folder, remove it's contents, and replace them with the contents of the server/default/deploy/jms folder.
  • Edit server/slim/deploy/jbossweb-tomcat55.sar/META-INF/jboss-service.xml to remove this fragment:

<!--
Needed if using HTTP Session Clustering or if the
ClusteredSingleSignOn valve is enabled in the tomcat server.xml file
-->
<depends>jboss.cache:service=TomcatClusteringCache</depends>

If you do not use distributed (clustered) web sessions

• Remove server/slim/deploy/tc5-cluster-service.xml (OR server/slim/deploy/tc5-cluster.sar on 4.0.4 or later)
• Edit server/slim/deploy/jbossweb-tomcat55.sar/META-INF/jboss-service.xml to remove this fragment:

<!--
Needed if using HTTP Session Clustering or if the
ClusteredSingleSignOn valve is enabled in the tomcat server.xml file
-->
<depends>jboss.cache:service=TomcatClusteringCache</depends>

If you do not use the Farm service (replicated deployments)

• Remove server/slim/farm
• Remove server/slim/deploy/deploy.last/farm-service.xml

Click here for a complete list of service dependencies.