Issue Details (XML | Word | Printable)

Key: JMS_SPEC-91
Type: Improvement Improvement
Status: Open Open
Priority: Major Major
Assignee: Unassigned
Reporter: Nigel Deakin
Votes: 0
Watchers: 1
Operations

If you were logged in you would be able to see more operations.
jms-spec

New "relaxed message order" option

Created: 28/Mar/12 01:56 PM   Updated: 28/Mar/12 01:56 PM
Component/s: None
Affects Version/s: 1.1
Fix Version/s: None

Time Tracking:
Not Specified

Tags: pd20-forreview-minor
Participants: Nigel Deakin


 Description  « Hide

Not all JMS applications depend on the message ordering guarantees required by JMS 1.1. Some would work perfectly well if the existing guarantees were occasionally broken.

The need to satisfy the message ordering requirements of JMS 1.1 imposes a significant burden on the JMS provider. For example, the requirement to preserve the order of messages sent by a message producer during the lifetime of the client-side object places constraints on the way in which a clustered JMS provider may handle producer failover or on its ability to balance the message load across the cluster.

Whilst JMS providers will always need to be able to satisfy JMS 1.1 message ordering requirements, if JMS also defined a less onerous message order requirement then those applications which could use it may be able to benefit from better performance or increased scalability.

It is therefore proposed that a new "relaxed" message ordering option be available. In such a mode, JMS does not guarantee that messages will always be received by a consumer in the same order that they were sent by a given producer. Although JMS providers could not be permitted to ignore message order altogether, the strict requirement to deliver messages in order would be relaxed.

It is expected that this option would be of particular value in very large clusters and similar web-scale architectures. However it would be up to providers to decide whether, and how, to take advantage of this option. Although vendors would be required to allow "relaxed message order" as an option, it would be completely valid for this to be identical to normal message ordering.

The exact API to specify "relaxed ordering" is not yet proposed. It might be a property of the producer connection or of the destination itself.



There are no entries against this issue.