Advanced Administration

Securing Access to Destinations

To apply a rolebased Access Control List to a Destination?s configuration, you must configure two attributes on the destination:

• The SecurityManager attribute must point to a JBossMQ SecurityManager.

• The SecurityConf attribute will hold the rolebased security configuration for the destination. It is composed of a security XML element with zero or more ?role? sub elements. A sample configuration is shown in Listing 5.1.

Listing 5.1 Sample Destination Security Configuration

"org.jboss.mq.server.jmx.Queue"
name="jboss.mq.destination:service=Queue,name=POInbox">
"DestinationManager">
jboss.mq:service=DestinationManager

"SecurityManager">
jboss.mq:service=SecurityManager

"SecurityConf">

"guest" read="false"
write="true"/>
"durablesub" read="true"
write="false" create="true"/>

Listing 5.1 sets up two roles. The first is a guest role that is allowed to only write to the destination. The second role is only allowed to read from the destination and create a durable subscription. The attributes that can be set on the role element are:

• name: The name of the role to which you are adding a security permission.

• read: You must set to true or false. The default is false if not set. Set to true to allow any clients who have the named role to receive messages from the destination.

• write: You must set to true or false. The default is false if not set. Set to true to allow any clients who have the named role to send or publish messages to the destination.

• create: You must set to true or false. The default is false if not set. Set to true to allow any clients who have the named role to create durable subscriptions for the destination.

Choosing An Invocation Layer

The Invocation Layer (IL) is the component that is responsible for defining the communications protocol that allows clients to send messages to a destination, and similarly, for the destination to send messages to the clients. JBossMQ can support running different types of Invocation Layers concurrently. All Invocation Layers have a dual channel nature that allows clients to send messages as it concurrently receives messages from the server.

Each different type of Invocation Layer will bind a JMS ConnectionFactory (configured to use the IL) to a different location in the JNDI tree. Clients can pick the protocol they wish to use by looking up the correct JNDI location.

JBossMQ currently supports four different ILs. This section will further examine these ILs.

RMI IL

The first Invocation Layer that was developed was based on Java?s Remote Method Invocation (RMI). This is a very robust IL since it is based on standard RMI technology. The RMI IL should be used when your client application has multiple threads sharing one connection.

Network Configuration

This IL will try to establish a TCP/IP socket from the server to the client. Therefore, clients that sit behind firewalls or have security restrictions prohibiting the use of SeverSockets should not use this IL.

OIL IL

The next Invocation Layer that was developed was the ?Optimized? IL (OIL). The OIL uses a custom TCP/IP protocol and serialization protocol that has very low overhead. This is the recommended protocol to be used since it has the best general-purpose performance characteristics.

Network Configuration

This IL will try to establish a TCP/IP socket from the server to the client. Therefore, clients that sit behind firewalls or have security restrictions prohibiting the use of SeverSockets should not use this IL.

UIL IL

The Unified Invocation Layer (UIL) was developed to allow Applet clients to connect to the server. It is almost identical to the OIL protocol except that a multiplexing layer is used to provide the dual channel characteristics of the IL. The multiplexing layer creates two virtual sockets over one physical socket. This IL is slower than the OIL due to the higher overhead incurred by the multiplexing layer.

JVM IL

The Java Virtual Machine (JVM) Invocation Layer was developed to cut out the TCP/IP overhead when the JMS client is running in the same JVM as the server. This IL uses direct method calls for the server to service the client requests. This increases efficiency since no sockets are created and there is no need for the associated worker threads. This is the IL that should be used by Message Driven Beans (MDB) or any other component that runs in the same virtual machine as the server such as servlets or MBeans.

Choosing A Message Data Store.

The Persistence Manager (PM) is used by a destination to store messages marked as being persistent. JBossMQ has several different implementations of the Persistent Manager, but only one can be enabled per server instance. You should enable the Persistence Manager that best matches your requirements.

This section will give you a brief description of the three types of PMs.

File PM

The File PM is one of the most robust Persistence Manager that comes with JBossMQ. It creates separate directories for each of the destination created on the server. It then stores each persistent message as a separate file in the appropriate directory. It does not have the best performance characteristics since it is frequently opening and closing files.

Rolling Logged PM

The Rolling Logged PM is also a file based Persistence Manager but it has better performance than the File PM because it stores multiple messages in one file reducing the file opening and closing overhead. This is a very fast PM but it is less transactionaly reliable than the File PM due to its reliance on the FileOutputStream.flush() method call. On some operating systems/JVMs the FileOutputStream.flush() method does not guarantee that the data has been written to disk by the time the call returns.

JDBC2 PM

The JDBC2 PM is the second version of the original JDBC PM in JBossMQ 2.4.x. It has been substantially simplified and improved. This PM allows you to store persistent messages to relational database using JDBC. The performance of this PM is directly related to the performance that can be obtained from the database. This PM has a very low memory overhead compared to the other Persistence Managers. Furthermore it is also highly integrated with the Message Cache to provide efficient persistence on a system that has a very active Message Cache.

Checking how many messages are on a Queue

Sometimes it's good to know know how many messages have been delivered to a queue. You can check the current depth of the queue by using JMX.

The org.jboss.mq.server.jmx.Queue MBeans provides a QueueDepth attribute which reflects the current number of messages sitting on the given queue.

Tuning the Message Cache

The Message Cache exposes several attributes for you to monitor the performance of the Message Cache. The attributes that can be viewed via JMX are:

• HardRefCacheSize: The number of messages that the Message Cache forced to stay in memory by using a hard reference.

• SoftRefCacheSize: The number of messages that the Message Cache has persisted but that are still lingering around in memory as soft references due to the garbage collector not being eager to free up space.

• TotalCacheSize: The total number of messages that are being managed by the Cache Manager.

• CacheHits: The number of times a message was requested and it was found to be in memory.

• CacheMisses: The number of times a message was requested and it was not found in memory, such that a read from persistent storage was required to retrieve the message.