9.4. Message Loss

Many distributed systems support reliable message delivery, either point-to-point (one consumer and one provider) or group-based (many consumers and one provider). Even in the presence of failures, the semantics imposed on reliability usually mean the message will be delivered or the sender will be informed that it failed to reach the receiver. Often systems which employ reliable messaging implementations distinguish between a message being delivered to the recipient and it subsequently being processed by the recipient. For instance, simply sending the message to a service does not mean much if a subsequent crash of that same service occurs before it has had time to work on the contents of the message.

Within the JBoss Enterprise SOA Platform, JMS is the only transport you can use which gives the aforementioned failure semantics on message delivery and processing. If you use transacted sessions, (an optional part of the JMSEpr), it is possible to guarantee that messages are received and processed in the presence of failures. If a failure occurs during processing by the service, the message will be placed back on the JMS queue for later re-processing. However, transacted sessions can be significantly slower than non-transacted sessions and so should be used with caution.

Because none of the other transports supported by the product come with transactional or reliable delivery guarantees, it is possible for messages to be lost. However, in most situations, the likelihood of this occurring is small. Unless there is a simultaneous failure of both sender and receiver (possible but not probable), the sender will be informed by the JBoss Enterprise SOA Platform about any failure to deliver the message. If a failure of the receiver occurs while processing and a response was expected, the receiver will eventually time-out and can retry.

For these reasons, using the message fail-over and re-delivery protocol is a good approach. If a failure of the service is suspected, then it will select an alternative EPR (assuming one is available,) and use it. However, if this suspicion of failure is wrong, it is possible that multiple services will operate on the same message concurrently. Therefore, although it offers a more robust approach to fail-over, it should be used with care. It works best where your services are stateless and idempotent. (In other words, the execution of the same message multiple times is the same as executing it once.)

For many services and applications, this type of re-delivery mechanism is fine. The robustness it provides over a single EPR can be a significant advantage. The failure modes where it does not work (such as when the client and service fails or is incorrectly assumed to have failed) are relatively uncommon. If your services cannot be idempotent, then you should either use JMS or code your services to be able to detect re-transmissions and cope with multiple services performing the same work concurrently.