|
RSS Feed - WebSphere MQ Support
|
RSS Feed - Message Broker Support
|
 |
|
Connecting out terminal of MQInput node to 2 nodes |
« View previous topic :: View next topic » |
Author |
Message
|
Om |
Posted: Tue Dec 02, 2003 9:22 am Post subject: Connecting out terminal of MQInput node to 2 nodes |
|
|
Novice
Joined: 11 Aug 2003 Posts: 12
|
Out terminal of MQInput node of my flow is connected to a Filter node.
I need to keep backup of all the messages I receive on MQInput node.
So I connected the out terminal(I can ignore failures) of MQInput node to a MQOutput node also.
Now I have a problem. Only half of the messages that I receive MQInput
go to MQOuput node and rest half go to Filter node.
I was not expected that behaviour. What I am doing wrong?
I need to keep the backup of the all the messages as they contniue to be processed by the flow.
Please help. _________________ -Om |
|
Back to top |
|
 |
jefflowrey |
Posted: Tue Dec 02, 2003 10:07 am Post subject: |
|
|
Grand Poobah
Joined: 16 Oct 2002 Posts: 19981
|
You probably have an error somewhere along the path that includes your Filter node.
When WMQI encounters two paths connected to the same terminal, it will randomly go down one of them until that path completes. It will then go down the other path.
However, if it goes down one of those paths, and encounters an error, it will roll everything back to the first point where you catch an error. So, if the failure terminal of the node that encouters the error is connected, it will go there. Otherwise it will roll back to the first TryCatch node it encounters. Otherwise, it will roll all the way back to the catch terminal on the Input node.
So, again we suppose you have an error in your Filter node path. We have two cases.
Case 1: A message goes to the Output node first, because that path is randomly chosen half the time. The Output node succeeds. The message then ALSO goes down the Filter path (as you expected, when you connected both nodes to the Output terminal). The message then errors out. The message on the Output node was not rolled back, because you have wisely set up the transactionality to Commit the message immediately.
Case 2: A message goes to the Filter node first. It errors out, and rolls back. It never goes to the Output node because everything has been rolled back to the Input node Catch terminal. _________________ I am *not* the model of the modern major general. |
|
Back to top |
|
 |
zpat |
Posted: Wed Dec 03, 2003 3:20 am Post subject: |
|
|
 Jedi Council
Joined: 19 May 2001 Posts: 5866 Location: UK
|
I think there is a flow order feature (or something like that) on later releases to allow more control over the order of the path taken. |
|
Back to top |
|
 |
jefflowrey |
Posted: Wed Dec 03, 2003 5:58 am Post subject: |
|
|
Grand Poobah
Joined: 16 Oct 2002 Posts: 19981
|
zpat wrote: |
I think there is a flow order feature (or something like that) on later releases to allow more control over the order of the path taken. |
Yes. There are two options. One is the "FlowOrder" Node. But this only has a limited sequence. I think it only has three outputs, so only three steps.
The other is a series of RouteToLabel and Label nodes, which essentially are named GOTOS. But you can build a list of Labels (DestinationList.labelname[]), and the RouteToLabel node will either jump to the first one in the list, or the last one and pop the label off the list. To walk through the whole list, you keep going to the same (or another) RouteToLabel node.
But neither of these are going to prevent an error down one path from interfering with the execution of the other paths. _________________ I am *not* the model of the modern major general. |
|
Back to top |
|
 |
|
|
 |
|
Page 1 of 1 |
|
You cannot post new topics in this forum You cannot reply to topics in this forum You cannot edit your posts in this forum You cannot delete your posts in this forum You cannot vote in polls in this forum
|
|
|
|