| Author |
Message
|
| javaforvivek |
 Posted: Wed Jun 01, 2005 3:16 am Post subject: Termination of MSg Flow with nodes other than output nodes |
 |
|
Master
Joined: 14 Jun 2002
Posts: 282
Location: Pune,India
|
Hi,
We have a situation where a msg flow stores all the data from a msg to a DB using Compute Node with no further processing. How should I terminate this msg flow?
One idea is that end the msg flow with the compute node and that's it.
Other idea is that end the msg flow with a MQOutput Node with output queue = DeadLetterQueue.
What I am really interested in is that what happens to a msg which is processed by the compute node, but then the msg flow is terminated?
_________________
Vivek
------------------------------------------------------
...when you have eliminated the impossible, whatever remains, however improbable, must be the truth. |
|
| Back to top |
|
 |
| nathanw |
| Posted: Wed Jun 01, 2005 3:29 am Post subject: |
|
|
Knight
Joined: 14 Jul 2004
Posts: 550
|
As far as I am aware whatever the message is when it hits the last node in a flow it ends there.
The flow does not have to end with an outputnode, infact I ahve in the past when integrating an app with Workflow (app was legacy) had several flows ending in a database insert.
Once completed processing the message, again as far as i know is dropped by broker as it is not required anymore.
If you feel that there may be a requirement to keep the message temporarily then have multiple outputs from another node ending in the database insert and a separate connection to an output node
Best way is to test and find out |
|
| Back to top |
|
|
| shalabh1976 |
| Posted: Wed Jun 01, 2005 3:29 am Post subject: |
|
|
Partisan
Joined: 18 Jul 2002
Posts: 381
Location: Gurgaon, India
|
Don't connect any node after the compute node. The message just falls into an unknown zone.
But I am worried about why you would want to do such a thing. You may want to somehow know that the message parsing occured successfully.
The least you can do is to set a database flag or generate a small output message that tells you of a successful parse.
_________________
Shalabh
IBM Cert. WMB V6.0
IBM Cert. MQ V5.3 App. Prog.
IBM Cert. DB2 9 DB Associate |
|
| Back to top |
|
|
| jefflowrey |
| Posted: Wed Jun 01, 2005 3:35 am Post subject: |
|
|
Grand Poobah
Joined: 16 Oct 2002
Posts: 19981
|
| shalabh1976 wrote: |
Don't connect any node after the compute node. The message just falls into an unknown zone.
But I am worried about why you would want to do such a thing. You may want to somehow know that the message parsing occured successfully.
The least you can do is to set a database flag or generate a small output message that tells you of a successful parse. |
The point of the flow is to perform a database insert... so he shouldn't need to set a different flag in the database to say that he can update a database... 
It's not an "unknown zone". The message flow has ended successfully, and therefore the GET is committed and the message flow releases it's memory.
This is the same thing that happens AFTER an MQOutput node.
_________________
I am *not* the model of the modern major general. |
|
| Back to top |
|
|
| javaforvivek |
| Posted: Wed Jun 01, 2005 3:41 am Post subject: |
|
|
Master
Joined: 14 Jun 2002
Posts: 282
Location: Pune,India
|
Guys,
Thanks for the quick replies.
nathanw wrote:
| Code: |
infact I ahve in the past when integrating an app with Workflow (app was legacy) had several flows ending in a database insert.
|
Did it affect your throughput of messages and performance of the msg flows??
shalabh wrote:
| Quote: |
The message just falls into an unknown zone.
|
What do you mean by 'Unknown Zone'? Is it somewhere in the memory? Then, something should be done to release this memory.
| Quote: |
But I am worried about why you would want to do such a thing. You may want to somehow know that the message parsing occured successfully.
|
It's like this: If the database inserts fails, the message will go to Error Handler msg flow, and error/exception is handled. If there is no error message, then we can check in the database whether the data is really inserted or not. Again, at the end of insert, it also inserts a predecided status code in one of the tables. So we are already doing what you suggested: 'The least you can do is to set a database flag'.
But why to unnecessarily do further processing to generate a small output msg? We don's want to keep the msg in the system (nor on a queue or file system) because we don't want it any more.
Again, when we are talking about 'Unknown Zone', what does that mean???
_________________
Vivek
------------------------------------------------------
...when you have eliminated the impossible, whatever remains, however improbable, must be the truth. |
|
| Back to top |
|
|
| jefflowrey |
| Posted: Wed Jun 01, 2005 3:48 am Post subject: |
|
|
Grand Poobah
Joined: 16 Oct 2002
Posts: 19981
|
| javaforvivek wrote: |
| Again, when we are talking about 'Unknown Zone', what does that mean??? |
It means nothing.
Like I said, the message flow ends normally, the get is committed, and the memory used by the flow is freed - following the normal rules for freeing memory from flows.
_________________
I am *not* the model of the modern major general. |
|
| Back to top |
|
|
| nathanw |
| Posted: Wed Jun 01, 2005 4:07 am Post subject: |
|
|
Knight
Joined: 14 Jul 2004
Posts: 550
|
| javaforvivek wrote: |
nathanw wrote:
| Code: |
infact I ahve in the past when integrating an app with Workflow (app was legacy) had several flows ending in a database insert.
|
Did it affect your throughput of messages and performance of the msg flows??
|
No affect what so ever infact it improved it slightly as there were no additional steps and as jeff says it released the memory earlier |
|
| Back to top |
|
|
|
|
