| |
|
RSS Feed - WebSphere MQ Support
|
RSS Feed - Message Broker Support
|
| FlowOrder and Compute Node bug? |
« View previous topic :: View next topic » |
| Author |
Message
|
| swu |
 Posted: Fri Dec 11, 2009 1:25 pm Post subject: FlowOrder and Compute Node bug? |
 |
|
Newbie
Joined: 11 Dec 2009
Posts: 5
|
I had an interesting test recently, I'd like to ask some experts here to see if this is a bug of WMB (MQSI 6.1.0.2)
Here is the Flow:
....................... --<breakPoint1>->Compute--<breakPoint2>>MQOutPut1
....................... |
MQInput-->FlowOrder
....................... |
....................... -----<breakPoint3>----------------------------->MQOutPut2
Input Message:
<Root>
<Node1>111</Node1>
<Node2>222</Node2>
</Root>
Documentation about FlowOrder node:
(link will be post later, cannot post url link with first post.)
...
The message that is propagated through the second output terminal is the input message; it is not modified in any way, even if the sequence of nodes that is connected to the first terminal has modified the message.
...
Test Case 1 with ESQL in Compute node:
SET OutputRoot = InputRoot;
SET OutputRoot.XMLNSC.Root.Node1 = 'new';
SET OutputRoot.XMLNSC.Root.Node2 = NULL;
Output messages are exactly like stated in the document. No question here.
Output1:
<?xml version="1.0" encoding="UTF-8"?>
<Root>
<Node1>new</Node1>
</Root>
Output2:
<Root>
<Node1>111</Node1>
<Node2>222</Node2>
</Root>
Test Case 2 with ESQL in Compute node:
SET OutputRoot = InputRoot;
SET InputRoot.XMLNSC.Root.Node1 = 'new';
--Compiler error, Input correlation name "InputRoot" cannot be changed.
SET InputRoot.XMLNSC.Root.Node2 = NULL; --Compiler error, Input correlation name "InputRoot" cannot be changed.
Perfect, No question here.
Test Case 3 with ESQL in Compute node:
SET OutputRoot = InputRoot;
DECLARE myRef REFERENCE TO InputRoot.XMLNSC.Root;
SET myRef.Node1 = 'new';
SET myRef.Node2 = NULL;
Output1:
<?xml version="1.0" encoding="UTF-8"?>
<Root>
<Node1>111</Node1>
<Node2>222</Node2>
</Root>
Output2:
<?xml version="1.0" encoding="UTF-8"?>
<Root>
<Node1>new</Node1>
</Root>
Here are my the questions for Test Case 3:
Q1, If you don't let me change InputRoot, why I can do it after reference?
Q2, I changed the input message in the Esql, why the output message at breakPoint2 is still as same as breakPoint1?
Q3, Intereating enough, at breakPoint3, the message is modified as what is supposed to have at breakPoint2, which is the message modified by the ESQL.
Many thanks to anyone can help me clear my confusion.
Last edited by swu on Fri Dec 11, 2009 2:11 pm; edited 3 times in total |
|
| Back to top |
|
 |
| swu |
| Posted: Fri Dec 11, 2009 1:27 pm Post subject: |
|
|
Newbie
Joined: 11 Dec 2009
Posts: 5
|
|
| Back to top |
|
|
| SANTYP |
| Posted: Tue Dec 15, 2009 7:36 pm Post subject: Re: FlowOrder and Compute Node bug? |
|
|
Centurion
Joined: 27 Mar 2007
Posts: 142
|
| swu wrote: |
I had an interesting test recently, I'd like to ask some experts here to see if this is a bug of WMB (MQSI 6.1.0.2)
Here is the Flow:
....................... --<breakPoint1>->Compute--<breakPoint2>>MQOutPut1
....................... |
MQInput-->FlowOrder
....................... |
....................... -----<breakPoint3>----------------------------->MQOutPut2
Input Message:
<Root>
<Node1>111</Node1>
<Node2>222</Node2>
</Root>
Documentation about FlowOrder node:
(link will be post later, cannot post url link with first post.)
...
The message that is propagated through the second output terminal is the input message; it is not modified in any way, even if the sequence of nodes that is connected to the first terminal has modified the message.
...
Test Case 1 with ESQL in Compute node:
SET OutputRoot = InputRoot;
SET OutputRoot.XMLNSC.Root.Node1 = 'new';
SET OutputRoot.XMLNSC.Root.Node2 = NULL;
Output messages are exactly like stated in the document. No question here.
Output1:
<?xml version="1.0" encoding="UTF-8"?>
<Root>
<Node1>new</Node1>
</Root>
Output2:
<Root>
<Node1>111</Node1>
<Node2>222</Node2>
</Root>
Test Case 2 with ESQL in Compute node:
SET OutputRoot = InputRoot;
SET InputRoot.XMLNSC.Root.Node1 = 'new';
--Compiler error, Input correlation name "InputRoot" cannot be changed.
SET InputRoot.XMLNSC.Root.Node2 = NULL; --Compiler error, Input correlation name "InputRoot" cannot be changed.
Perfect, No question here.
Test Case 3 with ESQL in Compute node:
SET OutputRoot = InputRoot;
DECLARE myRef REFERENCE TO InputRoot.XMLNSC.Root;
SET myRef.Node1 = 'new';
SET myRef.Node2 = NULL;
Output1:
<?xml version="1.0" encoding="UTF-8"?>
<Root>
<Node1>111</Node1>
<Node2>222</Node2>
</Root>
Output2:
<?xml version="1.0" encoding="UTF-8"?>
<Root>
<Node1>new</Node1>
</Root>
Here are my the questions for Test Case 3:
Q1, If you don't let me change InputRoot, why I can do it after reference?
Q2, I changed the input message in the Esql, why the output message at breakPoint2 is still as same as breakPoint1?
Q3, Intereating enough, at breakPoint3, the message is modified as what is supposed to have at breakPoint2, which is the message modified by the ESQL.
Many thanks to anyone can help me clear my confusion. |
Q2: ans
If you observe what exactly u did in compute node in the testcase 3
u will find the answer ur self..
first step is u set outputroot to inputroot.. so what ever the message comming from input is copied to output... after that u changed ipputroot reference that won't reflect in ur output...
Q3: ans
the message is modified in the second 2nd break point becuase it modified in the first compute node...
and Q1 is good question.. probably in any language u can't change the inputroot but if u take reference or something else to that input u can change... |
|
| Back to top |
|
|
| rekarm01 |
| Posted: Wed Dec 16, 2009 12:20 am Post subject: Re: FlowOrder and Compute Node bug? |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 1415
|
| swu wrote: |
| I had an interesting test recently, I'd like to ask some experts here to see if this is a bug of WMB (MQSI 6.1.0.2) |
WMB does allow a compute node (or other nodes) to modify Input trees, because it's useful in certain (limited) situations. The documentation for the PROPAGATE statement indicates when a message tree can be modified, and when it can't.
| swu wrote: |
Q1, If you don't let me change InputRoot, why I can do it after reference?
Q2, I changed the input message in the Esql, why the output message at breakPoint2 is still as same as breakPoint1?
Q3, Intereating enough, at breakPoint3, the message is modified as what is supposed to have at breakPoint2, which is the message modified by the ESQL. |
A1: WMB also makes the Input correlation names read-only, probably to discourage users from accidentally modifying Input trees.
A2: InputRoot and OutputRoot are two different trees. Changes to one don't affect the other.
A3: See A2. |
|
| Back to top |
|
|
| Gaya3 |
| Posted: Wed Dec 16, 2009 12:58 am Post subject: |
|
|
Jedi
Joined: 12 Sep 2006
Posts: 2493
Location: Boston, US
|
|
| Back to top |
|
|
| elvis_gn |
| Posted: Wed Dec 16, 2009 1:21 am Post subject: Re: FlowOrder and Compute Node bug? |
|
|
Padawan
Joined: 08 Oct 2004
Posts: 1905
Location: Dubai
|
Hi,
| rekarm01 wrote: |
| swu wrote: |
| I had an interesting test recently, I'd like to ask some experts here to see if this is a bug of WMB (MQSI 6.1.0.2) |
WMB does allow a compute node (or other nodes) to modify Input trees, because it's useful in certain (limited) situations. |
This is interesting...can you please paste the snippet which said you could change the input tree.
| swu wrote: |
Test Case 3 with ESQL in Compute node:
SET OutputRoot = InputRoot;
DECLARE myRef REFERENCE TO InputRoot.XMLNSC.Root;
SET myRef.Node1 = 'new';
SET myRef.Node2 = NULL;
Output1:
<?xml version="1.0" encoding="UTF-8"?>
<Root>
<Node1>111</Node1>
<Node2>222</Node2>
</Root>
Output2:
<?xml version="1.0" encoding="UTF-8"?>
<Root>
<Node1>new</Node1>
</Root> |
Q1's Ans: When you tried to SET the InputRoot, the compiler understood that you are trying to change the input tree, so it threw and error. But if you use a reference, you can point it on Input and then on Output and then on whatever, the compiler can't be expected to track the whole code to see if the SET is on input or output references.
Q2's Ans: Covered well by the other guys.
Q3's Ans: This is not possible, if it happened then it's a bug...but I would want to see a file trace of your input, path1 and path2 messages before I could accept it (as FlowOrder has been part of the product quite long now).
Regards. |
|
| Back to top |
|
|
| swu |
| Posted: Wed Dec 16, 2009 8:41 am Post subject: Re: FlowOrder and Compute Node bug? |
|
|
Newbie
Joined: 11 Dec 2009
Posts: 5
|
Thank you all for your replies.
| elvis_gn wrote: |
Q3's Ans: This is not possible, if it happened then it's a bug...but I would want to see a file trace of your input, path1 and path2 messages before I could accept it (as FlowOrder has been part of the product quite long now).
Regards. |
Here is the souce code:
CREATE COMPUTE MODULE MyFlowOrderTest_Compute
CREATE FUNCTION Main() RETURNS BOOLEAN
BEGIN
-- CALL CopyMessageHeaders();
-- CALL CopyEntireMessage();
SET OutputRoot = InputRoot;
--SET OutputRoot.XMLNSC.Root.Node1 = 'new';
--SET OutputRoot.XMLNSC.Root.Node2 = NULL;
--SET InputRoot.XMLNSC.Root.Node1 = 'new'; --Compiler error, Input correlation name "InputRoot" cannot be changed.
--SET InputRoot.XMLNSC.Root.Node2 = NULL; --Compiler error, Input correlation name "InputRoot" cannot be changed.
DECLARE myRef REFERENCE TO InputRoot.XMLNSC.Root;
SET myRef.Node1 = 'new';
SET myRef.Node2 = NULL;
RETURN TRUE;
END;
END MODULE;
And this is the trace, I am afraid it will be reformatted after I post it, don't know if I can post it as attachment.
Timestamps are formatted in local time, 420 minutes before GMT.
Trace written by version 6102; formatter version 6102
2009-12-16 09:28:25.173326 7544 UserTrace BIP4040I: The Execution Group ''default3'' has processed a configuration message successfully.
A configuration message has been processed successfully. Any configuration changes have been made and stored persistently.
No user action required.
2009-12-16 09:28:25.173822 7544 UserTrace BIP2638I: The MQ output node 'ConfigurationMessageFlow.outputNode' attempted to write a message to queue ''SYSTEM.BROKER.EXECUTIONGROUP.REPLY'' connected to queue manager ''QD01''. The MQCC was '0' and the MQRC was '0'.
2009-12-16 09:28:25.173847 7544 UserTrace BIP2622I: Message successfully output by output node 'ConfigurationMessageFlow.outputNode' to queue ''SYSTEM.BROKER.EXECUTIONGROUP.REPLY'' on queue manager ''QD01''.
2009-12-16 09:28:43.209300 6240 UserTrace BIP2632I: Message received and propagated to 'out' terminal of MQ input node 'MyFlowOrderTest.MQInput'.
2009-12-16 09:28:43.209362 6240 UserTrace BIP4163I: Message propagated to the first terminal of the FlowOrder node 'MyFlowOrderTest.FlowOrder'.
The FlowOrder node has received a message and has propagated it to the output terminal called first. Once the processing of the message down the first terminal has finished, the message will be propagated to the second terminal.
No user action required.
2009-12-16 09:28:43.209438 6240 UserTrace BIP6060I: Parser type ''Properties'' created on behalf of node 'MyFlowOrderTest.MQInput' to handle portion of incoming message of length 0 bytes beginning at offset '0'.
2009-12-16 09:28:43.209472 6240 UserTrace BIP6061I: Parser type ''MQMD'' created on behalf of node 'MyFlowOrderTest.MQInput' to handle portion of incoming message of length '364' bytes beginning at offset '0'. Parser type selected based on value ''MQHMD'' from previous parser.
2009-12-16 09:28:43.209529 6240 UserTrace BIP6061I: Parser type ''XMLNSC'' created on behalf of node 'MyFlowOrderTest.MQInput' to handle portion of incoming message of length '97' bytes beginning at offset '364'. Parser type selected based on value ''XMLNSC'' from previous parser.
2009-12-16 09:28:43.209690 6240 UserTrace BIP2537I: Node 'MyFlowOrderTest.Compute': Executing statement ''DECLARE INVALID_TABLE CHARACTER 'Invalid TableId - Can not find the proper table.';'' at ('.INVALID_TABLE', '1.1').
2009-12-16 09:28:43.209793 6240 UserTrace BIP2537I: Node 'MyFlowOrderTest.Compute': Executing statement ''DECLARE CODE_TRANSLATION_TABLE_EMPTY CHARACTER 'Query CodeTranslation returned zero rows - ' || 'there are no defined targets for this flow in the database.';'' at ('.CODE_TRANSLATION_TABLE_EMPTY', '1.1').
2009-12-16 09:28:43.230842 6240 UserTrace BIP2539I: Node 'MyFlowOrderTest.Compute': Evaluating expression '''Query CodeTranslation returned zero rows - ' || 'there are no defined targets for this flow in the database.''' at ('.CODE_TRANSLATION_TABLE_EMPTY', '1.102'). This resolved to '''Query CodeTranslation returned zero rows - ' || 'there are no defined targets for this flow in the database.'''. The result was '''Query CodeTranslation returned zero rows - there are no defined targets for this flow in the database.'''.
2009-12-16 09:28:43.230892 6240 UserTrace BIP2537I: Node 'MyFlowOrderTest.Compute': Executing statement ''DECLARE DEFAULT_VALUE_TABLE_EMPTY CHARACTER 'Query DefaultValue returned zero rows - ' || 'there are no defined targets for this flow in the database.';'' at ('.DEFAULT_VALUE_TABLE_EMPTY', '1.1').
2009-12-16 09:28:43.230926 6240 UserTrace BIP2539I: Node 'MyFlowOrderTest.Compute': Evaluating expression '''Query DefaultValue returned zero rows - ' || 'there are no defined targets for this flow in the database.''' at ('.DEFAULT_VALUE_TABLE_EMPTY', '1.99'). This resolved to '''Query DefaultValue returned zero rows - ' || 'there are no defined targets for this flow in the database.'''. The result was '''Query DefaultValue returned zero rows - there are no defined targets for this flow in the database.'''.
2009-12-16 09:28:43.230960 6240 UserTrace BIP2537I: Node 'MyFlowOrderTest.Compute': Executing statement ''DECLARE InputErrorQueue SHARED CONSTANT CHARACTER '';'' at ('.InputErrorQueue', '1.1').
2009-12-16 09:28:43.231067 6240 UserTrace BIP2537I: Node 'MyFlowOrderTest.Compute': Executing statement ''DECLARE XML_ENCODING INTEGER 273;'' at ('.XML_ENCODING', '1.1').
2009-12-16 09:28:43.231094 6240 UserTrace BIP2537I: Node 'MyFlowOrderTest.Compute': Executing statement ''DECLARE XML_CODEPAGE INTEGER 819;'' at ('.XML_CODEPAGE', '1.1').
2009-12-16 09:28:43.231124 6240 UserTrace BIP2537I: Node 'MyFlowOrderTest.Compute': Executing statement ''DECLARE Subject SHARED CONSTANT CHARACTER '';'' at ('.Subject', '1.1').
2009-12-16 09:28:43.231151 6240 UserTrace BIP2537I: Node 'MyFlowOrderTest.Compute': Executing statement ''DECLARE BackoutQueue SHARED CONSTANT CHARACTER '';'' at ('.BackoutQueue', '1.1').
2009-12-16 09:28:43.231178 6240 UserTrace BIP2537I: Node 'MyFlowOrderTest.Compute': Executing statement ''DECLARE ApplicationErrorQueue SHARED CONSTANT CHARACTER '';'' at ('.ApplicationErrorQueue', '1.1').
2009-12-16 09:28:43.231204 6240 UserTrace BIP2537I: Node 'MyFlowOrderTest.Compute': Executing statement ''DECLARE SystemErrorQueue SHARED CONSTANT CHARACTER '';'' at ('.SystemErrorQueue', '1.1').
2009-12-16 09:28:43.231243 6240 UserTrace BIP2537I: Node 'MyFlowOrderTest.Compute': Executing statement ''DECLARE ERNS1 NAMESPACE 'http://schemas.xmlsoap.org/soap/envelope/';'' at ('.ERNS1', '1.1').
2009-12-16 09:28:43.231277 6240 UserTrace BIP2537I: Node 'MyFlowOrderTest.Compute': Executing statement ''DECLARE TEMPNS NAMESPACE 'http://temp/';'' at ('.TEMPNS', '1.1').
2009-12-16 09:28:43.231300 6240 UserTrace BIP2537I: Node 'MyFlowOrderTest.Compute': Executing statement ''BEGIN ... END;'' at ('.MyFlowOrderTest_Compute.Main', '2.2').
2009-12-16 09:28:43.231445 6240 UserTrace BIP2537I: Node 'MyFlowOrderTest.Compute': Executing statement ''SET OutputRoot = InputRoot;'' at ('.MyFlowOrderTest_Compute.Main', '5.3').
2009-12-16 09:28:43.231967 6240 UserTrace BIP2539I: Node 'MyFlowOrderTest.Compute': Evaluating expression ''InputRoot'' at ('.MyFlowOrderTest_Compute.Main', '5.20'). This resolved to ''InputRoot''. The result was ''ROW... Root Element Type=16777216 NameSpace='' Name='Root' Value=NULL''.
2009-12-16 09:28:43.231994 6240 UserTrace BIP2568I: Node 'MyFlowOrderTest.Compute': Copying sub-tree from ''InputRoot'' to ''OutputRoot''.
2009-12-16 09:28:43.232059 6240 UserTrace BIP2537I: Node 'MyFlowOrderTest.Compute': Executing statement ''DECLARE myRef REFERENCE TO InputRoot.XMLNSC.Root;'' at ('.MyFlowOrderTest_Compute.Main', '10.3').
2009-12-16 09:28:43.232151 6240 UserTrace BIP2537I: Node 'MyFlowOrderTest.Compute': Executing statement ''SET myRef.Node1 = 'new';'' at ('.MyFlowOrderTest_Compute.Main', '11.3').
2009-12-16 09:28:43.232181 6240 UserTrace BIP2566I: Node 'MyFlowOrderTest.Compute': Assigning value '''new''' to field / variable ''myRef.Node1''.
2009-12-16 09:28:43.232250 6240 UserTrace BIP2537I: Node 'MyFlowOrderTest.Compute': Executing statement ''SET myRef.Node2 = NULL;'' at ('.MyFlowOrderTest_Compute.Main', '12.3').
2009-12-16 09:28:43.232280 6240 UserTrace BIP2567I: Node 'MyFlowOrderTest.Compute': Assigning NULL to ''myRef.Node2'', thus deleting it.
2009-12-16 09:28:43.232311 6240 UserTrace BIP2537I: Node 'MyFlowOrderTest.Compute': Executing statement ''RETURN TRUE;'' at ('.MyFlowOrderTest_Compute.Main', '14.3').
2009-12-16 09:28:43.232349 6240 UserTrace BIP4007I: Message propagated to 'out' terminal of node 'MyFlowOrderTest.Compute'.
2009-12-16 09:28:43.232475 6240 UserTrace BIP2638I: The MQ output node 'MyFlowOrderTest.MQOutput' attempted to write a message to queue ''WM.TEST.OUT'' connected to queue manager ''''. The MQCC was '0' and the MQRC was '0'.
2009-12-16 09:28:43.232494 6240 UserTrace BIP2622I: Message successfully output by output node 'MyFlowOrderTest.MQOutput' to queue ''WM.TEST.OUT'' on queue manager ''''.
2009-12-16 09:28:43.232528 6240 UserTrace BIP4164I: Message propagated to the second terminal of the FlowOrder node 'MyFlowOrderTest.FlowOrder'.
The FlowOrder node has finished processing a message down the first terminal and has propagated it to the second terminal.
No user action required.
2009-12-16 09:28:43.232635 6240 UserTrace BIP2638I: The MQ output node 'MyFlowOrderTest.MQOutput1' attempted to write a message to queue ''WM.TEST.OUT'' connected to queue manager ''''. The MQCC was '0' and the MQRC was '0'.
2009-12-16 09:28:43.232658 6240 UserTrace BIP2622I: Message successfully output by output node 'MyFlowOrderTest.MQOutput1' to queue ''WM.TEST.OUT'' on queue manager ''''.
2009-12-16 09:29:02.274671 7544 UserTrace BIP2632I: Message received and propagated to 'out' terminal of MQ input node 'ConfigurationMessageFlow.InputNode'.
2009-12-16 09:29:02.274792 7544 UserTrace BIP6060I: Parser type ''Properties'' created on behalf of node 'ConfigurationMessageFlow.InputNode' to handle portion of incoming message of length 0 bytes beginning at offset '0'.
2009-12-16 09:29:02.274828 7544 UserTrace BIP6061I: Parser type ''MQMD'' created on behalf of node 'ConfigurationMessageFlow.InputNode' to handle portion of incoming message of length '364' bytes beginning at offset '0'. Parser type selected based on value ''MQHMD'' from previous parser.
2009-12-16 09:29:02.274893 7544 UserTrace BIP6061I: Parser type ''XMLS'' created on behalf of node 'ConfigurationMessageFlow.InputNode' to handle portion of incoming message of length '206' bytes beginning at offset '364'. Parser type selected based on value ''XMLS'' from previous parser.
Threads encountered in this trace:
6240 7544 |
|
| Back to top |
|
|
| elvis_gn |
| Posted: Wed Dec 16, 2009 9:03 am Post subject: |
|
|
Padawan
Joined: 08 Oct 2004
Posts: 1905
Location: Dubai
|
Hi swu,
By file trace I meant using Trace nodes to capture the ${Root}...before the FlowOrder, after flowOrder(on both paths), and after compute.
The trace that you have pasted shows processing only till the MQOutput1, which is working as expected...My concern is with the output you suggested was coming out of the MQOutput2.
Regards. |
|
| Back to top |
|
|
| swu |
| Posted: Wed Dec 16, 2009 10:14 am Post subject: |
|
|
Newbie
Joined: 11 Dec 2009
Posts: 5
|
| elvis_gn wrote: |
Hi swu,
By file trace I meant using Trace nodes to capture the ${Root}...before the FlowOrder, after flowOrder(on both paths), and after compute.
The trace that you have pasted shows processing only till the MQOutput1, which is working as expected...My concern is with the output you suggested was coming out of the MQOutput2.
Regards. |
Sorry I misunderstood it.
I just simply added 3 Trace nodes at where my 3 break points are (see my first post please). Here are all the messages:
1. Input Message:
<?xml version="1.0" encoding="UTF-8"?>
<Root>
<Node1>111</Node1>
<Node2>222</Node2>
</Root>
2. Trace Point 1 (same as input):
( ['MQROOT' : 0x15d6ad40]
(0x01000000):Properties = ( ['MQPROPERTYPARSER' : 0x16b939f8]
(0x03000000):MessageSet = '' (CHARACTER)
(0x03000000):MessageType = '' (CHARACTER)
(0x03000000):MessageFormat = '' (CHARACTER)
(0x03000000):Encoding = 546 (INTEGER)
(0x03000000):CodedCharSetId = 437 (INTEGER)
(0x03000000):Transactional = TRUE (BOOLEAN)
(0x03000000):Persistence = FALSE (BOOLEAN)
(0x03000000):CreationTime = GMTTIMESTAMP '2009-12-16 18:06:06.400' (GMTTIMESTAMP)
(0x03000000):ExpirationTime = -1 (INTEGER)
(0x03000000):Priority = 0 (INTEGER)
(0x03000000):ReplyIdentifier = X'000000000000000000000000000000000000000000000000' (BLOB)
(0x03000000):ReplyProtocol = 'MQ' (CHARACTER)
(0x03000000):Topic = NULL
(0x03000000):ContentType = '' (CHARACTER)
(0x03000000):IdentitySourceType = '' (CHARACTER)
(0x03000000):IdentitySourceToken = '' (CHARACTER)
(0x03000000):IdentitySourcePassword = '' (CHARACTER)
(0x03000000):IdentitySourceIssuedBy = '' (CHARACTER)
(0x03000000):IdentityMappedType = '' (CHARACTER)
(0x03000000):IdentityMappedToken = '' (CHARACTER)
(0x03000000):IdentityMappedPassword = '' (CHARACTER)
(0x03000000):IdentityMappedIssuedBy = '' (CHARACTER)
)
(0x01000000):MQMD = ( ['MQHMD' : 0xb732840]
(0x03000000):SourceQueue = 'WM.TEST.IN' (CHARACTER)
(0x03000000):Transactional = TRUE (BOOLEAN)
(0x03000000):Encoding = 546 (INTEGER)
(0x03000000):CodedCharSetId = 437 (INTEGER)
(0x03000000):Format = ' ' (CHARACTER)
(0x03000000):Version = 2 (INTEGER)
(0x03000000):Report = 0 (INTEGER)
(0x03000000):MsgType = 8 (INTEGER)
(0x03000000):Expiry = -1 (INTEGER)
(0x03000000):Feedback = 0 (INTEGER)
(0x03000000):Priority = 0 (INTEGER)
(0x03000000):Persistence = 0 (INTEGER)
(0x03000000):MsgId = X'414d51205144303120202020202020208d02104b20896f0e' (BLOB)
(0x03000000):CorrelId = X'000000000000000000000000000000000000000000000000' (BLOB)
(0x03000000):BackoutCount = 0 (INTEGER)
(0x03000000):ReplyToQ = ' ' (CHARACTER)
(0x03000000):ReplyToQMgr = 'QD01 ' (CHARACTER)
(0x03000000):UserIdentifier = 'uj58 ' (CHARACTER)
(0x03000000):AccountingToken = X'16010515000000da246b0ad6658c16914cdd25a22c010000000000000000000b' (BLOB)
(0x03000000):ApplIdentityData = ' ' (CHARACTER)
(0x03000000):PutApplType = 11 (INTEGER)
(0x03000000):PutApplName = 'am Files\RFHUtil\rfhutil.exe' (CHARACTER)
(0x03000000):PutDate = DATE '2009-12-16' (DATE)
(0x03000000):PutTime = GMTTIME '18:06:06.400' (GMTTIME)
(0x03000000):ApplOriginData = ' ' (CHARACTER)
(0x03000000):GroupId = X'000000000000000000000000000000000000000000000000' (BLOB)
(0x03000000):MsgSeqNumber = 1 (INTEGER)
(0x03000000):Offset = 0 (INTEGER)
(0x03000000):MsgFlags = 0 (INTEGER)
(0x03000000):OriginalLength = -1 (INTEGER)
)
(0x01000000):XMLNSC = ( ['xmlnsc' : 0x1701bd90]
(0x01000400):XmlDeclaration = (
(0x03000100):Version = '1.0' (CHARACTER)
(0x03000100):Encoding = 'UTF-8' (CHARACTER)
)
(0x01000000):Root = (
(0x03000000):Node1 = '111' (CHARACTER)
(0x03000000):Node2 = '222' (CHARACTER)
)
)
)
3. Trace Point 2 (same as input, no changed):
( ['MQROOT' : 0x562ff58]
(0x01000000):Properties = ( ['MQPROPERTYPARSER' : 0x1719d9d0]
(0x03000000):MessageSet = '' (CHARACTER)
(0x03000000):MessageType = '' (CHARACTER)
(0x03000000):MessageFormat = '' (CHARACTER)
(0x03000000):Encoding = 546 (INTEGER)
(0x03000000):CodedCharSetId = 437 (INTEGER)
(0x03000000):Transactional = TRUE (BOOLEAN)
(0x03000000):Persistence = FALSE (BOOLEAN)
(0x03000000):CreationTime = GMTTIMESTAMP '2009-12-16 18:06:06.400' (GMTTIMESTAMP)
(0x03000000):ExpirationTime = -1 (INTEGER)
(0x03000000):Priority = 0 (INTEGER)
(0x03000000):ReplyIdentifier = X'000000000000000000000000000000000000000000000000' (BLOB)
(0x03000000):ReplyProtocol = 'MQ' (CHARACTER)
(0x03000000):Topic = NULL
(0x03000000):ContentType = '' (CHARACTER)
(0x03000000):IdentitySourceType = '' (CHARACTER)
(0x03000000):IdentitySourceToken = '' (CHARACTER)
(0x03000000):IdentitySourcePassword = '' (CHARACTER)
(0x03000000):IdentitySourceIssuedBy = '' (CHARACTER)
(0x03000000):IdentityMappedType = '' (CHARACTER)
(0x03000000):IdentityMappedToken = '' (CHARACTER)
(0x03000000):IdentityMappedPassword = '' (CHARACTER)
(0x03000000):IdentityMappedIssuedBy = '' (CHARACTER)
)
(0x01000000):MQMD = ( ['MQHMD' : 0x16bdba30]
(0x03000000):SourceQueue = 'WM.TEST.IN' (CHARACTER)
(0x03000000):Transactional = TRUE (BOOLEAN)
(0x03000000):Encoding = 546 (INTEGER)
(0x03000000):CodedCharSetId = 437 (INTEGER)
(0x03000000):Format = ' ' (CHARACTER)
(0x03000000):Version = 2 (INTEGER)
(0x03000000):Report = 0 (INTEGER)
(0x03000000):MsgType = 8 (INTEGER)
(0x03000000):Expiry = -1 (INTEGER)
(0x03000000):Feedback = 0 (INTEGER)
(0x03000000):Priority = 0 (INTEGER)
(0x03000000):Persistence = 0 (INTEGER)
(0x03000000):MsgId = X'414d51205144303120202020202020208d02104b20896f0e' (BLOB)
(0x03000000):CorrelId = X'000000000000000000000000000000000000000000000000' (BLOB)
(0x03000000):BackoutCount = 0 (INTEGER)
(0x03000000):ReplyToQ = ' ' (CHARACTER)
(0x03000000):ReplyToQMgr = 'QD01 ' (CHARACTER)
(0x03000000):UserIdentifier = 'uj58 ' (CHARACTER)
(0x03000000):AccountingToken = X'16010515000000da246b0ad6658c16914cdd25a22c010000000000000000000b' (BLOB)
(0x03000000):ApplIdentityData = ' ' (CHARACTER)
(0x03000000):PutApplType = 11 (INTEGER)
(0x03000000):PutApplName = 'am Files\RFHUtil\rfhutil.exe' (CHARACTER)
(0x03000000):PutDate = DATE '2009-12-16' (DATE)
(0x03000000):PutTime = GMTTIME '18:06:06.400' (GMTTIME)
(0x03000000):ApplOriginData = ' ' (CHARACTER)
(0x03000000):GroupId = X'000000000000000000000000000000000000000000000000' (BLOB)
(0x03000000):MsgSeqNumber = 1 (INTEGER)
(0x03000000):Offset = 0 (INTEGER)
(0x03000000):MsgFlags = 0 (INTEGER)
(0x03000000):OriginalLength = -1 (INTEGER)
)
(0x01000000):XMLNSC = ( ['xmlnsc' : 0xb702018]
(0x01000400):XmlDeclaration = (
(0x03000100):Version = '1.0' (CHARACTER)
(0x03000100):Encoding = 'UTF-8' (CHARACTER)
)
(0x01000000):Root = (
(0x03000000):Node1 = '111' (CHARACTER)
(0x03000000):Node2 = '222' (CHARACTER)
)
)
)
4. Trace Point 3 (message changed):
( ['MQROOT' : 0x15d6ad40]
(0x01000000):Properties = ( ['MQPROPERTYPARSER' : 0x16b939f8]
(0x03000000):MessageSet = '' (CHARACTER)
(0x03000000):MessageType = '' (CHARACTER)
(0x03000000):MessageFormat = '' (CHARACTER)
(0x03000000):Encoding = 546 (INTEGER)
(0x03000000):CodedCharSetId = 437 (INTEGER)
(0x03000000):Transactional = TRUE (BOOLEAN)
(0x03000000):Persistence = FALSE (BOOLEAN)
(0x03000000):CreationTime = GMTTIMESTAMP '2009-12-16 18:06:06.400' (GMTTIMESTAMP)
(0x03000000):ExpirationTime = -1 (INTEGER)
(0x03000000):Priority = 0 (INTEGER)
(0x03000000):ReplyIdentifier = X'000000000000000000000000000000000000000000000000' (BLOB)
(0x03000000):ReplyProtocol = 'MQ' (CHARACTER)
(0x03000000):Topic = NULL
(0x03000000):ContentType = '' (CHARACTER)
(0x03000000):IdentitySourceType = '' (CHARACTER)
(0x03000000):IdentitySourceToken = '' (CHARACTER)
(0x03000000):IdentitySourcePassword = '' (CHARACTER)
(0x03000000):IdentitySourceIssuedBy = '' (CHARACTER)
(0x03000000):IdentityMappedType = '' (CHARACTER)
(0x03000000):IdentityMappedToken = '' (CHARACTER)
(0x03000000):IdentityMappedPassword = '' (CHARACTER)
(0x03000000):IdentityMappedIssuedBy = '' (CHARACTER)
)
(0x01000000):MQMD = ( ['MQHMD' : 0xb732840]
(0x03000000):SourceQueue = 'WM.TEST.IN' (CHARACTER)
(0x03000000):Transactional = TRUE (BOOLEAN)
(0x03000000):Encoding = 546 (INTEGER)
(0x03000000):CodedCharSetId = 437 (INTEGER)
(0x03000000):Format = ' ' (CHARACTER)
(0x03000000):Version = 2 (INTEGER)
(0x03000000):Report = 0 (INTEGER)
(0x03000000):MsgType = 8 (INTEGER)
(0x03000000):Expiry = -1 (INTEGER)
(0x03000000):Feedback = 0 (INTEGER)
(0x03000000):Priority = 0 (INTEGER)
(0x03000000):Persistence = 0 (INTEGER)
(0x03000000):MsgId = X'414d51205144303120202020202020208d02104b20896f0e' (BLOB)
(0x03000000):CorrelId = X'000000000000000000000000000000000000000000000000' (BLOB)
(0x03000000):BackoutCount = 0 (INTEGER)
(0x03000000):ReplyToQ = ' ' (CHARACTER)
(0x03000000):ReplyToQMgr = 'QD01 ' (CHARACTER)
(0x03000000):UserIdentifier = 'uj58 ' (CHARACTER)
(0x03000000):AccountingToken = X'16010515000000da246b0ad6658c16914cdd25a22c010000000000000000000b' (BLOB)
(0x03000000):ApplIdentityData = ' ' (CHARACTER)
(0x03000000):PutApplType = 11 (INTEGER)
(0x03000000):PutApplName = 'am Files\RFHUtil\rfhutil.exe' (CHARACTER)
(0x03000000):PutDate = DATE '2009-12-16' (DATE)
(0x03000000):PutTime = GMTTIME '18:06:06.400' (GMTTIME)
(0x03000000):ApplOriginData = ' ' (CHARACTER)
(0x03000000):GroupId = X'000000000000000000000000000000000000000000000000' (BLOB)
(0x03000000):MsgSeqNumber = 1 (INTEGER)
(0x03000000):Offset = 0 (INTEGER)
(0x03000000):MsgFlags = 0 (INTEGER)
(0x03000000):OriginalLength = -1 (INTEGER)
)
(0x01000000):XMLNSC = ( ['xmlnsc' : 0x1701bd90]
(0x01000400):XmlDeclaration = (
(0x03000100):Version = '1.0' (CHARACTER)
(0x03000100):Encoding = 'UTF-8' (CHARACTER)
)
(0x01000000):Root = (
(0x03000000):Node1 = 'new' (CHARACTER)
)
)
)
5. Output from top path:
<?xml version="1.0" encoding="UTF-8"?>
<Root>
<Node1>111</Node1>
<Node2>222</Node2>
</Root>
6. Output from bottom path:
<?xml version="1.0" encoding="UTF-8"?>
<Root>
<Node1>new</Node1>
</Root>
Thanks again. |
|
| Back to top |
|
|
| kimbert |
| Posted: Wed Dec 16, 2009 2:13 pm Post subject: |
|
|
Jedi Council
Joined: 29 Jul 2003
Posts: 5542
Location: Southampton
|
| Quote: |
| this is the trace, I am afraid it will be reformatted after I post it |
Put [code] tags around traces, and anything else that needs a monospace font. |
|
| Back to top |
|
|
| rekarm01 |
| Posted: Wed Dec 16, 2009 3:42 pm Post subject: Re: FlowOrder and Compute Node bug? |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 1415
|
| elvis_gn wrote: |
| This is interesting...can you please paste the snippet which said you could change the input tree. |
From the text discussing the FINALIZE clause of the PROPAGATE statement:
| Quote: |
The Compute node allows its output message to be changed by other nodes (by the other nodes changing their input message). However, a message created by a Compute node cannot be changed by another node after:- It has been finalized
- It has reached any output or other node which generates a bit-stream
|
|
|
| Back to top |
|
|
| elvis_gn |
| Posted: Wed Dec 16, 2009 10:07 pm Post subject: Re: FlowOrder and Compute Node bug? |
|
|
Padawan
Joined: 08 Oct 2004
Posts: 1905
Location: Dubai
|
Hi,
| rekarm01 wrote: |
| elvis_gn wrote: |
| This is interesting...can you please paste the snippet which said you could change the input tree. |
From the text discussing the FINALIZE clause of the PROPAGATE statement:
| Quote: |
The Compute node allows its output message to be changed by other nodes (by the other nodes changing their input message). However, a message created by a Compute node cannot be changed by another node after:- It has been finalized
- It has reached any output or other node which generates a bit-stream
|
|
The statement "by the other nodes changing their input message" was meant to mean "by the other nodes which are capable of changing their InputRoot by creating an OutputRoot, such as a compute, JCN etc (an not a filter, Trace etc nodes which only have Root and are unchangeable)".
@swu:Looks to be a bug, unless this was how it was meant to work (which would mean I'd got it wrong allllll these years). Maybe you should raise a PMR and ask IBM for a clarification.
Regards. |
|
| Back to top |
|
|
| rekarm01 |
| Posted: Thu Dec 17, 2009 2:18 am Post subject: Re: FlowOrder and Compute Node bug? |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 1415
|
| elvis_gn wrote: |
| The statement "by the other nodes changing their input message" was meant to mean "by the other nodes which are capable of changing their InputRoot by creating an OutputRoot, such as a compute, JCN etc ...". |
These nodes can already modify their own OutputRoot, regardless of whether their InputRoot is finalized, (or serialized). If that's really what that statement was meant to mean, what would be the point of making FINALIZE optional? What would this subsequent statement be meant to mean?
| Quote: |
| If FINALIZE is set to NONE, no finalization takes place. This option is required if you want to preserve and allow updates of the entire output message tree by the nodes downstream in the message flow ... |
The documentation could be more clear about this, but to suggest that it intended to describe modifying Output trees raises more questions than it answers.
However, as a practical matter, it's certainly safer to treat Input trees as if they were always immutable, even if they sometimes aren't. Just because a message flow might be able to modify an Input tree doesn't mean that it should.
| elvis_gn wrote: |
| @swu:Looks to be a bug, unless this was how it was meant to work (which would mean I'd got it wrong allllll these years). |
Maybe not allllll these years. The behavior has changed between WMQI 2.1 and WBI MB 5.0, and again between WMB 6.0 and WMB 6.1, as suggested here.
| elvis_gn wrote: |
| Maybe you should raise a PMR and ask IBM for a clarification. |
I agree. |
|
| Back to top |
|
|
| swu |
| Posted: Thu Dec 17, 2009 8:11 am Post subject: Re: FlowOrder and Compute Node bug? |
|
|
Newbie
Joined: 11 Dec 2009
Posts: 5
|
| Quote: |
@swu:Looks to be a bug, unless this was how it was meant to work (which would mean I'd got it wrong allllll these years). Maybe you should raise a PMR and ask IBM for a clarification.
Regards. |
I will try and let you all know if I have any feedback. |
|
| Back to top |
|
|
| Esa |
| Posted: Sun Dec 20, 2009 6:12 am Post subject: |
|
|
Grand Master
Joined: 22 May 2008
Posts: 1387
Location: Finland
|
I don't think this is a bug. This is the way it is supposed to work. I have been wrong all these years, too. 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 hoods.
It has never entered my mind to test this myself. I am happy somebody has done it now and opened my eyes.
So, FlowOrder node propagates the same memory area to both terminals and relies on the good programming practise that nobody should modify InputRoot. Even if using references of java API make it possible. If this "bug" was fixed, the node would have to create a new memory area and deep copy the message. That could have a significant performance impact on hundreds of thousands existing message flows all over the world. And FlowOrder is not the only node that wold have to be changed, I am quite sure that TryCatch and most Input nodes do it the same way (easy to test the same way you did with FlowOrder). I think I will run the tests myself as well.
Thanks, this was the most interesting thread for ages! |
|
| Back to top |
|
|
|
|
|
  |
Goto page 1, 2 Next |
Page 1 of 2 |
|
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
|
|
|
|
