Took me a couple of reads to understand what you're saying. That's a very elegant solution and one that indeed would ensure consistency with only the occasional "wasted" sleep.

Your final point about locks and consistency does give me some slight pause. Due to the speed of messages coming in I can see the possibility of collisions or deadlocks and while fairly small may be enough to consider going to the simpler approach of just creating additional BPLs we're currently using.

In any case, thank you very much for the guidance.

The change would mean that the number of processes could be increased programatically and while a production is running.

If the processed was stopped, queues drained and the pool size increased we'd then be able to have more processes running if we'd noticed a spike in messages (or wanted to increase for future). This would be easier than adding new BPLs into the production as it would only require a single setting change.

Thanks for the reply.

3 keys was only as an example :-), it could be up to n for the number of threads we'd create.

We'd be using an MRN, as we only require that messages for that patient are in order.

So MRN 123 would go to thread 123 mod n always
MRN 456 would go to thread 456 mod n always
etc.

Does that make the question any clearer?

The idea was the Parameter was in the routing rule itself, this way the function getFunctionValue would be run at compile time (as it's value won't change) rather than running it each time within the rule definition.

e.g.

Class MyRoutingRule Extends RuleDefinition {

Parameter myClassParameter = {#class(FunctionSet).GetFunctionValue()}

XData RuleDefinition {
  //use myClassParameter in here
}

}

I thought I'd also tried using the $parameter function as well, but perhaps I have to specify the class name as the first argument, even if the class is itself?

Thanks.