| Author |
Message
|
| smdavies99 |
 Posted: Sun May 12, 2013 6:02 am Post subject: |
 |
|
Jedi Council
Joined: 10 Feb 2003
Posts: 6076
Location: Somewhere over the Rainbow this side of Never-never land.
|
| Code: |
2013-05-12 12:46:21.358374 36404 UserTrace BIP3634I: Node 'FindByOutpassNoRequest' received HTTP data from host 'www.vision.ae' with status code of 404.
|
so what does that tell you?
_________________
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 |
|
 |
| sarathmattam |
| Posted: Sun May 12, 2013 8:52 pm Post subject: |
|
|
Voyager
Joined: 05 Sep 2008
Posts: 94
|
@ smdavies99 : Thanks for your reply. Thats true that am getting an error from the target. Thats expected as am testing retry scenario. When Target is not available or when i get a Socket or Time out exception, i should retry . For this i have connected a retry subflow which identifies the type of error and decides whether its a valid scenario for retry. if yes, it would be put in to another flow which put the message back in to the Input queue after a minute. but, all of this will happen only if the message comes back to the CATCH terminal and i have the values set in in Environment variables. But unfortunately its rolling back and getting committed due to some reason. I need your advice here ..
Regards,
Sarath |
|
| Back to top |
|
|
| mapa |
| Posted: Mon May 13, 2013 4:24 am Post subject: |
|
|
Master
Joined: 09 Aug 2001
Posts: 257
Location: Malmö, Sweden
|
Strange, do you have any more details?
Just to be sure I tried using the WMB7 Web Service Example that I modified slightly and it works as expected.
I stop the provider flow and then the consumer flow throws an exception and the message goes back to the mqinput node, then to the catch terminal where the Environment.variables is intact and then I throw exception to force the message to be backed out. After that it arrives on the failure.
Which version are you on and how is the flow built? |
|
| Back to top |
|
|
| rekarm01 |
| Posted: Mon May 13, 2013 11:10 am Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 1415
|
| sarathmattam wrote: |
| but, all of this will happen only if the message comes back to the CATCH terminal and i have the values set in in Environment variables. |
Is the error handler implemented as a WMBv8 subflow project? Prior to v8.0.0.2, there were known problems with multiply connected terminals for subflows. That would explain why the message gets backed out to the input queue, rather than handled by the catch flow. When the message flow backs out the transaction, it also discards any Environment.Variables.
| sarathmattam wrote: |
| Code: |
2013-05-12 12:46:22.361328 36404 UserTrace BIP2631I: Backed out message being propagated to failure terminal; node 'com.emaratech.vision.esb.event.outpass.VM_Outpass_Event.Outpass_EventIn'.
Node 'com.emaratech.vision.esb.event.outpass.VM_Outpass_Event.Outpass_EventIn' has received a message which has previously been backed out because of a processing error in the message flow. The MQMD 'backoutCount' of the message exceeds (or equals) the 'backoutThreshold' defined for the WebSphere MQ input queue. The message broker is propagating the message to the failure terminal of the node. |
|
The backout count exceeding the backout threshold would explain why the message flow routes any retries to the Failure terminal. |
|
| Back to top |
|
|
| sarathmattam |
| Posted: Tue May 14, 2013 9:52 pm Post subject: |
|
|
Voyager
Joined: 05 Sep 2008
Posts: 94
|
Thanks Mapa & Rekarm01 for your replies
I am using 8.0.01 and all my flows are built using this version.
Let me go through the link. |
|
| Back to top |
|
|
| sarathmattam |
| Posted: Tue May 14, 2013 10:02 pm Post subject: |
|
|
Voyager
Joined: 05 Sep 2008
Posts: 94
|
@ rekarm01 : That was a great piece of information
As mentioned in the link, i has 2 connections going out from the MQ Input node to the Retry Subflow. From both FAILURE and CATCH terminals. Now, i removed the connection from the FAILURE terminal and the retry work like charm. Thank You so much ..
However, what is the permanent solution. Upgrading to 8.0.0.2 ? Has any one started using it ?
Regards,
Sarath |
|
| Back to top |
|
|
| lancelotlinc |
| Posted: Wed May 15, 2013 3:09 am Post subject: |
|
|
Jedi Knight
Joined: 22 Mar 2010
Posts: 4941
Location: Bloomington, IL USA
|
Removing the connection from the Failure terminal simply means your likely no longer catching that error, not that the error has gone away. Do you have Trace nodes in your flow? Have you attended the required training classes (9 days of training)?
_________________
http://leanpub.com/IIB_Tips_and_Tricks
Save $20: Coupon Code: MQSERIES_READER |
|
| Back to top |
|
|
| sarathmattam |
| Posted: Wed May 15, 2013 4:33 am Post subject: |
|
|
Voyager
Joined: 05 Sep 2008
Posts: 94
|
@lancelotlinc : Thank you.. What you said is correct. But, then how did the message suddenly started flowing to the CATCH terminal when i removed the connection from FAILURE ?
Then for the time being, i have 2 instances of the sub flow. One connected to CATCH and the other with FAILURE
I dnt have a Trace node and I dint attend classroom sessions .. |
|
| Back to top |
|
|
| lancelotlinc |
| Posted: Wed May 15, 2013 4:34 am Post subject: |
|
|
Jedi Knight
Joined: 22 Mar 2010
Posts: 4941
Location: Bloomington, IL USA
|
See if you can sign up for the classroom training. When you attend, you can interact with the instructor and other students to arrive at good practices. One of those good practices is using Trace nodes. Trace nodes give you visibility into whats happening in your flow.
_________________
http://leanpub.com/IIB_Tips_and_Tricks
Save $20: Coupon Code: MQSERIES_READER |
|
| Back to top |
|
|
| praj1740 |
| Posted: Wed May 15, 2013 4:46 am Post subject: |
|
|
Apprentice
Joined: 05 Feb 2013
Posts: 29
Location: INDIA
|
Failure terminal:-Failures routed to this terminal include failures caused by the retry processing occurring before the retry propagates the message to the Out flow.
There is no catch terminal for the soap request node.Better place a trace node and specify the pattern and the file path where trace is to be written |
|
| Back to top |
|
|
| smdavies99 |
| Posted: Wed May 15, 2013 7:02 am Post subject: |
|
|
Jedi Council
Joined: 10 Feb 2003
Posts: 6076
Location: Somewhere over the Rainbow this side of Never-never land.
|
| praj1740 wrote: |
There is no catch terminal for the soap request node.Better place a trace node and specify the pattern and the file path where trace is to be written |
so what happens when this output file gets to be 100Mb or larger?
Really, writing data to files using trace nodes really has no place in Production in this day and age. Perhaps if we were still using V2.0.2 or V2.1 then yes but now? As one tennis player once said at Wimbledon, 'You can't be serious'.
This is most certainly (IMHO) not a 'Best Practice'
_________________
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 |
|
|
| lancelotlinc |
| Posted: Wed May 15, 2013 7:54 am Post subject: |
|
|
Jedi Knight
Joined: 22 Mar 2010
Posts: 4941
Location: Bloomington, IL USA
|
| smdavies99 wrote: |
| praj1740 wrote: |
There is no catch terminal for the soap request node.Better place a trace node and specify the pattern and the file path where trace is to be written |
so what happens when this output file gets to be 100Mb or larger?
Really, writing data to files using trace nodes really has no place in Production in this day and age. Perhaps if we were still using V2.0.2 or V2.1 then yes but now? As one tennis player once said at Wimbledon, 'You can't be serious'.
This is most certainly (IMHO) not a 'Best Practice' |
'erm. uh-hmmm. There is a mqsichangetrace command to turn off Trace nodes in Production.
This is most certainly (IMHO) a 'Best Practice'.
Trace nodes have four output choices, only one of them is a file.
_________________
http://leanpub.com/IIB_Tips_and_Tricks
Save $20: Coupon Code: MQSERIES_READER |
|
| Back to top |
|
|
| Vitor |
| Posted: Wed May 15, 2013 8:10 am Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| lancelotlinc wrote: |
| 'erm. uh-hmmm. There is a mqsichangetrace command to turn off Trace nodes in Production. |
erm. uh-hmmm squared. If you read the comment, the suggestion was to wire the Trace node to the catch terminal to capture the error. Are you suggesting Trace nodes are a best practice error handling technology?
| lancelotlinc wrote: |
| Trace nodes have four output choices, only one of them is a file. |
Again, the suggestion to which issue is being taken explicitly refers to a file path.
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| lancelotlinc |
| Posted: Wed May 15, 2013 8:22 am Post subject: |
|
|
Jedi Knight
Joined: 22 Mar 2010
Posts: 4941
Location: Bloomington, IL USA
|
| Vitor wrote: |
| lancelotlinc wrote: |
| 'erm. uh-hmmm. There is a mqsichangetrace command to turn off Trace nodes in Production. |
erm. uh-hmmm squared. If you read the comment, the suggestion was to wire the Trace node to the catch terminal to capture the error. Are you suggesting Trace nodes are a best practice error handling technology?
| lancelotlinc wrote: |
| Trace nodes have four output choices, only one of them is a file. |
Again, the suggestion to which issue is being taken explicitly refers to a file path. |
No, smdavies is objecting to using Trace nodes at all. I rarely use the word 'best' with 'practice'. Use of Trace nodes is a good practice.
I put a Trace node before and after every major node in all my flows. As to what gets output can be as simple as a single field. As to where it gets put is up to the BFO. I almost always include timestamps with my output. I also make extensive use of logger in all my Compute nodes.
Error handling and Trace nodes are not mutually exclusive, and usually the two are complementary to one another. Error handling requires logic. Trace nodes provide no logic, just eyes to puzzle.
_________________
http://leanpub.com/IIB_Tips_and_Tricks
Save $20: Coupon Code: MQSERIES_READER |
|
| Back to top |
|
|
| smdavies99 |
| Posted: Wed May 15, 2013 9:06 am Post subject: |
|
|
Jedi Council
Joined: 10 Feb 2003
Posts: 6076
Location: Somewhere over the Rainbow this side of Never-never land.
|
| lancelotlinc wrote: |
No, smdavies is objecting to using Trace nodes at all. I rarely use the word 'best' with 'practice'. Use of Trace nodes is a good practice.
|
WRONG WRONG WRONG.
I was objecting to the use of Trace Nodes to capture thibgs like ExceptionLists to a FILE.
That is IMHO is NOT BEST PRACTICE at all.
I do have message flows with Trace Nodes included. They most certainly are not configured to write to a file. They are configured as 'UserTrace'.
The other point I was making (or trying to make) was that using Trace Nodes to capture 'stuff' with the output sent to a file in this day an age is well past its sell by date. Yes I own up to using this back in the day of 2.0.2/2.1 but now? Never in a million years.
There are plenty of far better options not including IMHO Log4j as that has its own set of issues that have been well discussed here.
_________________
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 |
|
|
|
|
