[jboss-dev-forums] [Design of Messaging on JBoss (Messaging/JBoss)] - Message bridge committed

[timfox]

The new message bridge has been committed in TRUNK. http://jira.jboss.com/jira/browse/JBMESSAGING-264

The message bridge is a component which forwards messages from one destination to another. The source and target destinations can be one the same server
or on different remote servers.

The bridge should work with any JMS 1.1 compliant JMS server, although has only been tested with JBM.

The bridge comes as a non MBean class, and also has an MBean wrapper so can be deployed on the JBoss AS JMS spine.

When using the bridge you specify a desired quality of service, this can be one of:

QOS_AT_MOST_ONCE

With this QoS mode messages will reach the destination from the source at most once.
The messages are consumed from the source and acknowledged
before sending to the destination. Therefore there is a possibility that if failure occurs between removing them from the source and them arriving at the destination they could be lost. Hence delivery will occur at most once.
This mode is avilable for both persistent and non persistent messages.

QOS_DUPLICATES_OK

With this QoS mode, the messages are consumed from the source and then acknowledged after they have been successfully sent to the destination. Therefore there is a possibility that if failure occurs after sending to the destination but before acknowledging them, they could be sent again
when the system recovers. I.e. the destination might receive duplicates after a failure.
This mode is available for both persistent and non persistent messages.
    
QOS_ONCE_AND_ONLY_ONCE

This QoS mode ensures messages will reach the destination from the source once and only once.
(Sometimes this mode is known as "exactly once").
If both the source and the destination are on the same JBoss Messaging server instance (same resource manager) then this can be achieved by simply sending and acknowledging the messages in the same local transaction. The bridge will automatically detect this and use a local tx as appropriate.
If the source and destination are on different servers (different resource managers) this is achieved by enlisting the sending and consuming sessions in a JTA transaction. The JTA transaction is controlled by JBoss Transactions JTA implementation thus providing a very high degree of durability.
If JTA is required then both supplied connection factories need to be XAConnectionFactory implementations.
This mode is only available for persistent messages.
This is likely to be the slowest mode since it requires extra persistence for the transaction logging.
     
One thing to note:
For a specific application it may possible to provide once and only once semantics without using the
QOS_ONCE_AND_ONLY_ONCE QoS level. This can be done by using the QOS_DUPLICATES_OK mode and then checking for duplicates at the destination and discarding them. Some JMS servers provide automatic duplicate message detection functionality, or this may be possible to implement on the application level by maintaining a cache of received
message ids on disk and comparing received messages to them. The cache would only be valid for a certain period of time so this approach is not as watertight as using QOS_ONCE_AND_ONLY_ONCE but may be a good choice depending on your specific application but it less general than using JTA.

Other stuff:

The bridge can be started and stopped, or temporarily paused and resumed.

A maximum message batch size can be specified for the bridge, the bridge will then consume and forward messags in batches of this size.
This is likely to be more performant then consuming / sending one by one.

A maximum batch time can also be configured. If so, then if less than maxBatchSize messages have been consumed then the batch will be sent if the maxBatchTime
is exceeded. This allows messages to be sent sooner if there are long delays between messages.

The bridge can consume from a queue, or a durable or non durable subscription, and a forward to a queue or a topic.

A JMS selector can be specified for the bridge so it will only forward messages that match the selector criteria.

If the connection to the source or target destination is lost, then the bridge can be configured to retry at configurable intervals, and a configurable
number of times. This allows it to be more resilient to temporary network loss, especially useful for forwarding from one LAN to another across a brittle WAN.

There is a minor issue to resolve with transaction recovery but this is all pretty much done.

View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4003072#4003072

Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4003072