Null Persistence Manager Configuration

A wrapper persistence manager that can delegate to a real persistence manager.

Configuration on the destinations decide whether persistence and caching is actually performed.

The example configuration can be found in docs/examples/jms.

You need to change the ObjectName of the real persistence manager from the default jboss.mq:service=PersistenceManager.

WARNING: You have no protection on your memory for destinations that do not perform message softening

Clarification

TemporaryQueues, TemporaryTopics and NonDurableSubscriptions do not persist messages but they do take part in message softening

When using a Null Persistence Manager with no delegate to perform real storage, the message softening process will transfer messages from memory to ... memory. More precisely, the message will be transferred from the MessageCache to the Null Persistence Manager's internal cache, so using only a Null Persistence Manager does not offer you protection on your memory, regardless of the destination.

Example Configuration

1. Deploy the Null Persistence Manager

With the JBoss instance down, install the Null Persistence Manager by creating a new null-persistence-service.xml deployment descriptor in the deploy/jms directory. If you're using the clustered configuration, the directory to place the new file into is deploy-hasingleton/jms. The file is virtually identical with hsqldb-jdbc2-service.xml, except that is uses the Null Persistence Manager instead of JDBC2 Persistence Manager:

    ....
    <mbean code="org.jboss.mq.pm.none.PersistenceManager"
           name="jboss.mq:service=PersistenceManager">

           <!-- An optional delegate for real persistence of some destinations e.g. jdbc2 -->
           <!-- depends optional-attribute-name="DelegatePM">jboss.mq:service=SomePersistenceManager</depends-->
    </mbean>

You can use the sample from docs/examples/jms with no changes.

Configurable Attributes:

DelegateName

The real persistence manager for destinations that do want persistence. The delegate cannot be one of the legacy file persistence managers.

2. Disable the JDBC2 Persistence Manager

Prevent the JDBC2 Persistence Manager from deploying by removing its hsqldb-jdbc2-service.xml deployment descriptor from deploy/jms.

3. Deploy the file-based State Manager

Deploy the file-based State Manager by creating a new file-state-service.xml deployment descriptor in the deploy/jms directory. If you're using the clustered configuration, the directory to place the new file into is deploy-hasingleton/jms. This new deployment descriptor installs a State Manager that uses conf/jbossmq-state.xml to read/store durable subscription and user related state. You can use the samples file-state-service.xml and  conf/jbossmq-state.xml available in docs/exampes/jms with no changes.

4. Disable the JDBC State Manager

Prevent the JDBC State Manager from deploying by removing its hsqldb-jdbc-state-service.xml deployment descriptor from deploy/jms.

5. Configure security

Replace the current JBossMQ security configuration with the following login module in conf/login-config.xml:

    <application-policy name = "jbossmq">
       <authentication>
          <login-module code = "org.jboss.mq.sm.file.DynamicLoginModule"
             flag = "required">
             <module-option name = "unauthenticatedIdentity">guest</module-option>
             <module-option name = "sm.objectname">jboss.mq:service=StateManager</module-option>
          </login-module>
       </authentication>
    </application-policy>

Note: When sending PERSISTENT messages with a Null Persistence Manager installed, and if there is no persistence manager delegate,  the messages WON'T be stored to persistent storage. They will be only stored in memory, so if your JBossMQ instance crashes, the messages will be lost.