MQSeries.net :: View topic - MQInput Node (Logical Order & Order Mode)

MQSIGuy · Posted: Wed Mar 17, 2010 5:04 am Post subject:

Hi,

I'm currenlty having a problem with a flow in our production environment. The flow is a common component and used by all other flows which put messages to it.

Currently the flow is not performant and we are looking at 2 solutions.

(1) Multi-thread the flow although this may cause issues with the order of messages. At this time we have no guarantee that all apps don't require the messages in order so this is a requirement for any solution.

(2) Scale the execution group and deploy more instances of the flow - This is not a preferred option for the obvious reasons but also we are even less likely to guarantee the order of messages.

Looking at option (1) I was looking into the MQ Input node and the 'Order mode' and 'Logical Order' settings.

Does anyone know what the impact of using these two options together is? I understand it as changing the 'Order mode' setting to 'by queue' keeps the order of messages from the queue even if the flow is multi-threaded therefore treating the 'additional instancs' value as '0' anyway which defeats the purpose of mult--threading. But is this singular processing only created at the MQInput queue? Does the rest of the flow process multi-threaded? I ask because our performance problem with the flow is not at the MQ queue level(which can cause a funnel with one thread - one handlle getting from the queue) but the processing within the flow itself. So if multi-threaded plus order mode by queue equals a bottle neck at the MQ queue but multi-threaded for the flow and performance gains while keeping message order then great. Does anyone know if that is the case? The documentation doesn't seem to go into this detail.

Taking it one step further the 'logical order' check box guarantees 'to ensure that messages that are part of a message group are received in the order that has been assigned by the sending application.' Does anyone know if this is still the case when multi-threading the flow? And if these two properties were used in a multithreaded flow would this guarantee the correct order of messages received and put by the flow?

I understand strategically we can look to better design and develop the flow to make it more perfomrant etc. I also understand we can multi-thread the flow and use atomic processing perhaps but as this is a production issue we're looking for a simple and effective tactical fix at least in the short term that's the least intrusive to our current flow and set-up.

Any suggestions would be appreciated!