Dan, did you mean to imply that messages are no longer stored once they are acknowledged? This is not the case. Messages must be stored longer than persistDuration. In your scenario, when 12 got to the Receiving MSH, 1-10 are still in the store. If you wait so long that 1-10 have passed persistDuration, then I think you have waited so long that it does not matter any more. I see your point about what happens if there is nothing in the store and the Receiving MSH gets a message with a number larger than 1. However, this implies the last ordered message/MessageId (which has been delivered in order) must be stored indefinitely (forever?) which is probably not acceptable. This also points out the conflict between Message Order and persistDuration. What if messages 1,2,3,4 have persistDuration of 2 days. Messages 1,2,4 are delivered. The MSH hands 1,2 to the application but holds 4. For some reason, 3 is not delivered for 3 days. In this case 3,4 have already passed persistDuration so they are not delivered. The next day, 5 is delivered. Since 3,4 were not delivered, then 5 cannot be delivered (nor any subsequent messages) even though it is still within TTL, and the ordering is forever broken for this ConversationId. We may have to say Message Ordering does not work if any message in the order fails to be delivered within its persistDuration (or maybe TTL)? Of course, all this can be adjusted at run time by increasing the value of persistDuration in the CPA. Once again, MessageOrdering is based on persistDuration. I am wondering why are we messing with all of this? Did I see Marty suggest, if messages are order dependant, just wait for acknowledgment from the end before sending the next message? Sounds good. Regards, David.