Author |
Message
|
ghoshly |
Posted: Thu Jun 06, 2013 8:07 am Post subject: Time Out nodes - Environment is lost ?? - WMB 7.0.0.5 |
|
|
Partisan
Joined: 10 Jan 2008 Posts: 327
|
Hello,
I am using TimeOut nodes in controlled way to retry SOAP request after SocketException or SocketTimeoutException untill configured max retry attempt is reached, or the SOAP Request is sent successfully; which ever is first.
In this process I see the Environment tree is lost when message is coming out of TimeOut Notification node.
Is this is a expected behaviour ? I don't see any specification of Environment tree in infocentre in this regard.
When I am sending the TimeoutRequest again to the same Timeout control node, using the same code (as mentioned below) this time, no message is coming out of the TimeoutNotification node. I am getting exception from Failure terminal of TimeOutNotification node with BIP4619.
Code: |
SET OutputLocalEnvironment.TimeoutRequest.Action = 'SET';
SET OutputLocalEnvironment.TimeoutRequest.Identifier = 'TMC_Retry';
SET OutputLocalEnvironment.TimeoutRequest.StartDate = 'TODAY';
SET OutputLocalEnvironment.TimeoutRequest.StartTime = CURRENT_TIME + CAST(IN_TimeOut_Interval AS INTERVAL SECOND);
SET OutputLocalEnvironment.TimeoutRequest.Count = 1;
SET OutputLocalEnvironment.TimeoutRequest.IgnoreMissed = TRUE;
SET OutputLocalEnvironment.TimeoutRequest.AllowOverwrite = 'TRUE';
|
WMB - 7.0.0.5 Presently trying in Wndows 7
Would you please guide me where I am doing any wrong? |
|
Back to top |
|
|
lancelotlinc |
Posted: Thu Jun 06, 2013 8:28 am Post subject: |
|
|
Jedi Knight
Joined: 22 Mar 2010 Posts: 4941 Location: Bloomington, IL USA
|
The LocalEnvironment is not lost. You should be using Environment.Variables tree to store variables that you want to have a life longer than a few nodes. You should use V8 and Global Cache if you want variables to live longer than one flow.
Also, you may want to reconsider your approach. Soap nodes have their own timeout value and if your choice is to retry, then you should arrange to do so in your handler; not a timeout node. _________________ http://leanpub.com/IIB_Tips_and_Tricks
Save $20: Coupon Code: MQSERIES_READER |
|
Back to top |
|
|
mqjeff |
Posted: Thu Jun 06, 2013 8:36 am Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008 Posts: 17447
|
|
Back to top |
|
|
ghoshly |
Posted: Thu Jun 06, 2013 10:42 am Post subject: |
|
|
Partisan
Joined: 10 Jan 2008 Posts: 327
|
Thanks jeff for the response.. Now I understand why existing Environment variables tree is lost after timeout node...
Still don't understand why same TimeoutRequest code is working fine first time and generating thread, however next time it says failure.. |
|
Back to top |
|
|
McueMart |
Posted: Fri Jun 07, 2013 1:23 am Post subject: |
|
|
Chevalier
Joined: 29 Nov 2011 Posts: 490 Location: UK...somewhere
|
Add a Trace node before your TimeoutControl node and trace at least:
${Root}
==========
${LocalEnvironment}
to check that your two calls to create the Timeout are in fact identical. |
|
Back to top |
|
|
AkankshA |
Posted: Fri Jun 07, 2013 6:05 am Post subject: |
|
|
Grand Master
Joined: 12 Jan 2006 Posts: 1494 Location: Singapore
|
|
Back to top |
|
|
ghoshly |
Posted: Fri Jun 07, 2013 7:46 am Post subject: |
|
|
Partisan
Joined: 10 Jan 2008 Posts: 327
|
I am using that trick Akankha !!
It was just weird for me to loose Environment at the first hand. I hadn't thought about new thread.
I have connected trace node before the control node and couldn't found any difference. Not posting result here because I have quite big usr filder structure within MQRFH2.
I am in a doubt of using these within a sub-flow (currently doing). I'll take out these nodes out of sub-flow and would see if there is any difference.
Thanks a lot for your help. |
|
Back to top |
|
|
ghoshly |
Posted: Thu Jun 13, 2013 8:37 am Post subject: Sorry for late response |
|
|
Partisan
Joined: 10 Jan 2008 Posts: 327
|
I take out the logic out of subflow - but no good luck.
Local Environment trace :
Code: |
Current Time : 2013-06-13 22:02:45.174045
=============================
( ['MQROOT' : 0x1415c158]
(0x01000000:Name):TimeoutRequest = (
(0x03000000:NameValue):Action = 'SET' (CHARACTER)
(0x03000000:NameValue):Identifier = 'TMC_Retry' (CHARACTER)
(0x03000000:NameValue):StartDate = 'TODAY' (CHARACTER)
(0x03000000:NameValue):StartTime = TIME '22:02:50.173668' (TIME)
(0x03000000:NameValue):Count = 1 (INTEGER)
(0x03000000:NameValue):IgnoreMissed = TRUE (BOOLEAN)
(0x03000000:NameValue):AllowOverwrite = 'TRUE' (CHARACTER)
)
)
*******************Iteration***********************
Current Time : 2013-06-13 22:02:51.355911
=============================
( ['MQROOT' : 0x19576c28]
(0x01000000:Name):TimeoutRequest = (
(0x03000000:NameValue):Action = 'SET' (CHARACTER)
(0x03000000:NameValue):Identifier = 'TMC_Retry' (CHARACTER)
(0x03000000:NameValue):StartDate = 'TODAY' (CHARACTER)
(0x03000000:NameValue):StartTime = TIME '22:02:56.355428' (TIME)
(0x03000000:NameValue):Count = 1 (INTEGER)
(0x03000000:NameValue):IgnoreMissed = TRUE (BOOLEAN)
(0x03000000:NameValue):AllowOverwrite = 'TRUE' (CHARACTER)
)
)
*******************Iteration***********************
|
After 2 time, message is going out of Failure terminal of TimeOut notification node. Error details followed.
Code: |
<CombinedErrorDetails>
<BrokerDetails>
<BrokerName>LOCALBRK</BrokerName>
<EGName>Test</EGName>
<EGUUID>87a8dde5-3e01-0000-0080-91b571dcf4f9</EGUUID>
<BrokerPlatform>WINDOWS</BrokerPlatform>
<ComponentName>ICE_TMC_SOAPDispatcher_Retry</ComponentName>
<NodeName>CaptureError</NodeName>
</BrokerDetails>
<ExceptionList>
<RecoverableException>
<File>F:\build\S700_P\src\DataFlowEngine\TimeoutControl\ImbTimeoutNotificationNode.cpp</File>
<Line>1112</Line>
<Function>ImbTimeoutNotificationNode::propagateFailureDeleteMsg</Function>
<Type>ComIbmTimeoutNotificationNode</Type>
<Name>ICE_TMC_SOAPDispatcher_Retry#FCMComposite_1_16</Name>
<Label>ICE_TMC_SOAPDispatcher_Retry.Timeout Notification</Label>
<Catalog>BIPmsgs</Catalog>
<Severity>3</Severity>
<Number>4619</Number>
</RecoverableException>
</ExceptionList>
</CombinedErrorDetails>
|
|
|
Back to top |
|
|
psandip |
Posted: Thu Jun 13, 2013 11:22 pm Post subject: |
|
|
Novice
Joined: 11 Aug 2006 Posts: 17
|
@ghoshly...even i too am facing the same issue in our project.....
when we are taking trace of properties before timeout control node we can see that the reply protocol is at first set to 'MQ' in whihc case message comes out sucesfully out of timer notificaiotn node. Next time the reply protocol is unknown and message comes out of the failure terminal of timer notificaiton node. Hope this finding helps. _________________ With Best Regards,
Sandeep |
|
Back to top |
|
|
|