The SP2 release fixes a major concurrency bug (http://jira.jboss.com/jira/browse/JBMESSAGING-660 - a race condition that used to occur while closing sessions), a remoting bug (http://jira.jboss.com/jira/browse/JBMESSAGING-644) and also introduced changes in how redeliveries and sending messages to the Dead Letter Queue are handled. The configuration changes required by this new release are extensively described below.

WARNING! Due to the fact that the redelivery count per message is now maintained in the database, the database schema has changed, so the database tables need to be dropped and recreated upon restart.

The complete list of changes introduced by this release is available at http://jira.jboss.org/jira/secure/ReleaseNote.jspa?version=12311073&styleName=Html&projectId=12310061

Configuration changes introduced by JBoss Messaging 1.0.1.SP2

1. Configurable DLQ name and maximum delivery attempt count

The latest server version allows you to configure an arbitrary DLQ where messages will sent after a number of failed delivery attempts. The queue name can be specified using ServerPeer's DLQName attribute. The number of delivery attempts can be specified using ServerPeer's MaxDeliveryAttempts attribute.

Both attributes are part of ServerPeer service configuration, located in messaging-service.xml:

    <mbean code="org.jboss.jms.server.ServerPeer"
      name="jboss.messaging:service=ServerPeer"
      xmbean-dd="xmdesc/ServerPeer-xmbean.xml">

      ...

      <attribute name="MaxDeliveryAttempts">10</attribute>
      <attribute name="DLQName">DLQ</attribute>

   </mbean>

The queue to be used as DLQ must be declared in destinations-service.xml, so it will be deployed at boot.

2. Maximum redelivery attempts for EJB3 Message Driven Beans

For a JBoss 4.0.5 EJB3 MDB container, the maximum redelivery attempts attribute is set by default to 0, so the messages are sent straight to DLQ (http://jira.jboss.org/jira/browse/JBAS-3917).

To work around this, change the maximum delivery attempts counter in your EJB3 MDB configuration:

@MessageDriven(activationConfig =

{

      ...

      @ActivationConfigProperty(propertyName="DLQMaxResent", propertyValue="10")

})                                                                                

3. Remoting configuration changes

The remoting-service.xml needs to be changed, by adding the following two new attributes (as result of http://jira.jboss.org/jira/browse/JBMESSAGING-644) to the Connector's configuration:

<attribute name="clientSocketClass" isParam="true">org.jboss.jms.client.remoting.ClientSocketWrapper</attribute>
<attribute name="serverSocketClass">org.jboss.jms.server.remoting.ServerSocketWrapper</attribute>

Example:

<mbean code="org.jboss.remoting.transport.Connector" name="jboss.messaging:service=Connector,transport=socket" display-name="Socket transport Connector">
      <attribute name="Configuration">
         <config>
           
               <invoker transport="socket">
               ...
                      <attribute name="clientSocketClass" isParam="true">org.jboss.jms.client.remoting.ClientSocketWrapper</attribute>
                      <attribute name="serverSocketClass">org.jboss.jms.server.remoting.ServerSocketWrapper</attribute>
               ...
               </invoker>
         </config>

      </attribute>
   </mbean>

In case you use an SSL connector, the same attributes must be added to the SSL Connector's configuration.

4. Database schema changes

The number of delivery attempts is now recorded in the database. For this reason, the current server version requires a database schema change. 1.0.1.GA-created tables are incompatible with 1.0.1.SP2, so in order to use SP2, you need to drop the old tables and recreate them.

Referenced by: