New "relaxed message order" option

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.
#### Affected Versions
[1.1]

Start by reading the issue's JMS 1.1 affected-version context and the existing message-ordering requirements. No implementation files, tests, entry points, or API shape are identified; the work is not complete until the relaxed-ordering semantics and the API location are defined and implemented.

Written by the indexing model from the issue text.