Messages are processed from the queue based on arrival only and not by the SessionId - it may look in some cases that it is based on the SessionId but that is because the SessionId is the Message Header Id for the first message in the session and the Header Id is an incrementing counter.
One thing to bear in mind with BPL is that even with a pool size 1 it is possible for message ordering to become switched if the BPL makes non blocking calls (the default and strength of BPLs). See the docs on BPL and FIFO and reference to using of blocking coded SendRequestSync().
A custom option that some have used concern having dedicated hosts to do the long running conversion that have pool size 1 and a name using a numbering system so that messages can be routed based on a hashing of the FIFO key (LabReportId for example). Another custom option is maintaining a table of what is in progress and being able to delay processing until the other is finished.
The feature that Tani references has at its core a modification to the framework's DeQueuing mechanism to be able to skip a message if its FIFO key is the same as a message already in progress.
- Log in to post comments