Peter, >>>Assume this flow: >>> Input Node --> Compute Node1 ---> Compute Node2 ---> OutPut Node >>>If I put 10 messages on a queue, the Input Node picks up Message #1 and >>>assuming all is good sends it out it's Output terminal to Compute Node1. >>>If Compute Node1 successfully accepts Message #1, does the Input Node go to >>>get Message #2 even before Compute Node1 is done handling Message #1?
The thread that retrives a given message runs with that message through the entire flow. So the behavior really depends on whether the flow is configured to run with multiple threads (instances) or not. Each input node in a message flow is assigned a thread when the flow is started. However, in the Assignments view you have the option of assigning "additional instances" (i.e., support for additional threads of execution) to the message flow. If you did NOT do this (which is the default), then the single thread that retrives a given message will need to process that message to completion, through all the nodes in the flow, before it can return and retrieve another message from the queue. If the flow IS configured to run with multiple threads (instances), then EACH thread that retrives a given message will need to process that message to completion. However, what will happen is that once the message has been retrieved by the input node, the broker will assign another thread (if available) to listen on the queue. If a message arrives before completion of the previous message, it will be processed under this second thread, etc. >>>If yes, what happens to Message#2 if the Input Node sends it out it's Output >>>Terminal before Compute Node1 is done processing Message#1? What happens? Nothing bad, presumably. Processing nodes are expected to be thread-safe. However, it is possible your messages may leave the broker in a different order than they arrived in. If you have a sequencing requirement for messages on a particular queue than you probably don't want to assign additional instances to your message flow. >>>I guess the big question is, In a flow, if a preceding node is done handling >>>a message, but the following node is still busy with a prior message, what >>>happens to the message in the preceding node if it ready to leave that node? >>>Are these message being held in memory? >>>Or do the nodes all "talk" to each other to know when they are ready to >>>accept another message, in which case I would think sooner or later you >>>would see the original MQ queue backing up? >>>I have this question because no matter how fast we throw messages at MQSI, >>>the Input queue never seems to back up. The nodes pretty much run independently of each other. Each node can be seen as a dll (or shared library) that is invoked by the thread of execution that is processing a given message. This means that messages can be processed by the broker very quickly, particularly if additional instances are assigned to the message flow. All messages in flight are held in memory (although they may still be on the queue as well if the flow is transactional). On a machine with adaquate memory and processing power the messages can be processed very quickly. Hope this helps. Regards, Christopher Frank Sr. I/T Specialist - IBM Software Group IBM Certified Solutions Expert - Websphere MQ & MQ Integrator -------------------------------------------- Phone: 612-397-5532 (t/l 653-5532) mobile: 612-669-3008 e-mail: [EMAIL PROTECTED] Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com Archive: http://vm.akh-wien.ac.at/MQSeries.archive
