Factors that may affect the ordering of messages and how do
Help and comments are definitely needed, please!
Below is a sum of factors I found and how should an order group deal with them (by default). Some of the choices the order group impl makes may not be appropriate all the time, and if so, we can make them configurable to suit different needs.
1. Message Priority: messages with higher priorities may jump ahead of the messages with lower ones, even if the lower ones may have been created ahead of the higher ones;
/In Ordering Group/ -- Messages in an ordering group will be ignored of their priorities in the ordering of their delivery.
2. Persistency: Non-persistent messages and persistent ones. They are two seperate categories with respect to ordering. Non persistent messages are not guaranteed to survive a server failure and thus may mess up the ordering group processing.
/In Ordering Group/ -- We may force that all messages in the ordering group to be of PERSISTENT delivery mode.
3. Message redelivery: In case of message redelivery (if required), new messages may be delivered to the Queue the same time as that of redelivery.
/In Ordering Group/ -- the message to be redelivered, if in an ordering group, must block any subsequent messages that are in the same message ordering group.
4. Message Ack Modes -- dup_ok/auto/client, the three ack mode affects the acknowledgement timing but shouldn't change the message ordering group's behavior.
/In Ordering Group/ -- The order group will wait for the acknowledge of the current message before delivering the next one, regardless the ack mode.
5. Message selector -- the filtering of messages causes some messages not selected to drop from the subscribers.
/In Ordering Group/ -- We can forbid using selectors, or we can make the selector process always pass any messages that belong to an ordering group, or we can deem the drop of a unsatisfied message to be an effective acknowledgement of completion. Not sure!!
6. JMS Replyto -- during a ordered delivery, if some messages has reploy to header specified, this will yield another message delivery.
/In Odering Group/ -- We should ignore this case. as long as we get acked from the message delivery, we consider it's completed.
7. Expired/Dead Messages -- if some messages expires or failed to deliver for n times, they will go to the expiryQueue or DLQ. Consumer won't get them. If a dead or expired message drops from the ordering group, the order is broken.
/In Ordering Group/ -- We can treat all members in an ordering group as never expires or never be dead, or we treat expired message and dead message as unfinished until they are fetched from the expiryQueue or DLQ and acked (or the transaction containing those messages are committed or rolled back).
8. Transactions -- transactions makes the messages delivery subject to an atomic operation.
/In Ordering Group/ -- If any message in the ordering group is participates in any active transaction, its delivery won't be treated as completed until the transaction is committed or rolled back.
9. Ordering Scope -- messages can be sent from different sessions, on different connections, or from different client applications to different destinations (queues or topics).
/In Ordering Group/ -- We can guarantee the ordering delivery of a ordering group easily if all the messages in an ordering group are produced(sent) within one same session and all the messsages are targeted at one same destination. Messages from different sessions imply different work threads (which makes the message order depending on thread scheduling) and different transactions (which needs more care for ordering). Messages of an ordering group on different destinations is also hard to handle even if they are from one session.
10. ConnectionConsumer -- This is a special case of message delivery.
/In Ordering Group/ -- If messages of an ordering group is consumed this way, we should also keep the ordering correctly even if the consumer can handle the messages concurrently. But in this case we can't guarantee the messages are all processed by one same Session in the pool.
