| |
|
RSS Feed - WebSphere MQ Support
|
RSS Feed - Message Broker Support
|
| FlowOrder and Compute Node bug? |
« View previous topic :: View next topic » |
| Author |
Message
|
| smdavies99 |
 Posted: Sun Dec 20, 2009 8:22 am Post subject: |
 |
|
Jedi Council
Joined: 10 Feb 2003
Posts: 6076
Location: Somewhere over the Rainbow this side of Never-never land.
|
I think it is working as designed.
Just about the first thing I was taught when I took a broker class back in the 2.0.1 days, was to treat anything in the Input* folders as READ ONLY.
I've never had an issue with FlowOrder nodes being the cause of corruption probably because I still follow the Read Only rule that I was taught over 8 years ago. I just never even thought of trying to change it.
Now that I think about it, I'm even more of the opinion that trying to do this is a bad idea.
_________________
WMQ User since 1999
MQSI/WBI/WMB/'Thingy' User since 2002
Linux user since 1995
Every time you reinvent the wheel the more square it gets (anon). If in doubt think and investigate before you ask silly questions. |
|
| Back to top |
|
 |
| Esa |
| Posted: Sun Dec 20, 2009 10:57 am Post subject: |
|
|
Grand Master
Joined: 22 May 2008
Posts: 1387
Location: Finland
|
Exactly.
I must correct my previous reply. I ment to say that references AND java API make it possible to modify InputRoot. And I agree that doing it would in most cases be a bad idea. |
|
| Back to top |
|
|
| elvis_gn |
| Posted: Sun Dec 20, 2009 10:41 pm Post subject: |
|
|
Padawan
Joined: 08 Oct 2004
Posts: 1905
Location: Dubai
|
Hi,
I'm waiting for someone from the labs to end this confusion...even the use of FINALIZE clause needs some elaboration.
Regards. |
|
| Back to top |
|
|
| rekarm01 |
| Posted: Mon Dec 21, 2009 3:47 pm Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 1415
|
| Esa wrote: |
| I have even told my students to try to avoid certain nodes because I supposed they issue a deep copy of the message under the hood. |
Which nodes would that be?
The Compute node, for example, does not perform any deep copies "under the hood". Initially, it receives three Input trees, and creates three additional, empty, Output trees. The ESQL is responsible for populating the output trees; it might perform deep copies, but that's out in the open.
When propagating, either the "Compute mode" property or the PROPAGATE "MessageSources" clause determines which of the Input/Output trees to propagate, (regardless of which trees the Compute node actually modifies). |
|
| Back to top |
|
|
| rekarm01 |
| Posted: Mon Dec 21, 2009 5:30 pm Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 1415
|
| smdavies99 wrote: |
| Just about the first thing I was taught when I took a broker class back in the 2.0.1 days, was to treat anything in the Input* folders as READ ONLY. |
Back in the MQSI 2.0.1 days, the Input trees were READ ONLY. There were no reference variables, PROPAGATE statements, etc.; it might have been possible to modify Input trees with a C or Java custom node, but that's a little difficult to confirm at the moment.
The point of confusion is whether the rules have changed since then, and if so, how?
| smdavies99 wrote: |
| Now that I think about it, I'm even more of the opinion that trying to do this is a bad idea. |
More often than not, it probably is a bad idea. One scenario where it might seem useful though: a compute node propagates a message tree multiple times, and the downstream nodes apply cumulative modifications to that message tree instance. However, even if the original developer understood how to implement that correctly, the poor sap who inherits the code might decide it's all wrong, and try to "fix" it. For the cost of an extra tree copy, a much cleaner approach is to apply downstream modifications to the Environment tree instead (InputRoot -> Environment -> OutputRoot); Environment is always modifiable, and there's no need to worry about Input versus Output, or finalization.
| elvis_gn wrote: |
| I'm waiting for someone from the labs to end this confusion...even the use of FINALIZE clause needs some elaboration. |
Yes, that would help a lot. The documentation regarding finalization is a bit sparse, and sometimes unclear. Until the confusion is cleared up, it's probably best not to tinker with Input trees or FINALIZE clauses. |
|
| Back to top |
|
|
| Esa |
| Posted: Wed Dec 23, 2009 1:35 am Post subject: |
|
|
Grand Master
Joined: 22 May 2008
Posts: 1387
Location: Finland
|
| Esa wrote: |
| I have even told my students to try to avoid certain nodes because I supposed they issue a deep copy of the message under the hood. |
| rekarm01 wrote: |
Which nodes would that be?
|
What I meant is that I have incorrectly assumed that certain nodes make a deep copy of the message, and even told that to my students.
My assumption was that for example FlowOrder propagates an intact copy of InputRoot to both terminals. Which would invove taking a backup copy of InputRoot in FlowOrder before propagating to terminal 1 and propagating the copy to terminal 2. Which is NOT the way it happens or should happen. The results of test case 3 are correct and there is no bug.
Other nodes that operate similarly are for example MQInput and TryCatch. MQInput does not keep an extra copy of the message but propagates the same memory pointer to both Out and Catch terminals. So if you modify InputRoot in the main flow it is possible that the message that is propagated to catch is no longer the same message that was got from the queue. That should give you an idea why you should never modify InputRoot unless you have a very good reason and know exactly what you are doing and what consequences it may have. |
|
| Back to top |
|
|
|
|
|
|
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
|
|
|
|
