| Author |
Message
|
| master_jack |
 Posted: Fri May 25, 2012 3:06 am Post subject: Monitoring not happening with 'Throw' in Catch/fail path |
 |
|
Newbie
Joined: 22 May 2012
Posts: 4
|
In WMB8, for record and replay feature
When I add throw node to catch or fail path, the events are not captured.
But the same works fine in normal path.
The execution along the fail/catch path works fine. Just the monitoring events are not captured.
If anyone knows fully how the broker store the monitoring events, please reply to this thread.
Thanks. |
|
| Back to top |
|
 |
| antonpiatek |
| Posted: Fri May 25, 2012 5:27 am Post subject: |
|
|
Newbie
Joined: 22 Oct 2007
Posts: 5
Location: Hursley, UK
|
| Which events have you configured for recording? and on which nodes? |
|
| Back to top |
|
|
| lancelotlinc |
| Posted: Fri May 25, 2012 5:43 am Post subject: |
|
|
Jedi Knight
Joined: 22 Mar 2010
Posts: 4941
Location: Bloomington, IL USA
|
This could be by design? Record/replay feature records and replays successful messages not unsuccessful ones. Do you have a backout queue defined? Have you set the retry count?
_________________
http://leanpub.com/IIB_Tips_and_Tricks
Save $20: Coupon Code: MQSERIES_READER |
|
| Back to top |
|
|
| pmasters |
| Posted: Fri May 25, 2012 5:51 am Post subject: |
|
|
Novice
Joined: 19 Jul 2011
Posts: 14
|
Monitoring will capture the event if it passes through the terminal or the event point (transaction start/end/rollback). You say you're putting a try-catch into the flow - Is the monitoring event that you are capturing either associated with the input failure terminal (which a failure now won't reach as its caught elsewhere) or on transaction rollback (which won't occur because the flow is deemed successful if the failure is caught).
This sounds like the message is no longer passing through the point at which monitoring is applied?
One other thing to be aware of is that if you have redeployed a flow in an application/library then it resets your monitoring profile (it effectively deletes and recreates your app at the moment, so your profile is lost). If you have therefore re-deployed your flow then you might not be seeing emitted messages as the monitoring is not enabled any more.
Hope those things help, but we would probably need more detail to have a better clue whats going on here.
Cheers, Pete |
|
| Back to top |
|
|
| mqjeff |
| Posted: Fri May 25, 2012 6:03 am Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 17447
|
| pmasters wrote: |
| One other thing to be aware of is that if you have redeployed a flow in an application/library then it resets your monitoring profile (it effectively deletes and recreates your app at the moment, so your profile is lost). If you have therefore re-deployed your flow then you might not be seeing emitted messages as the monitoring is not enabled any more. |
That is entirely the wrong behavior and should be viewed as a defect. |
|
| Back to top |
|
|
| pmasters |
| Posted: Fri May 25, 2012 6:27 am Post subject: |
|
|
Novice
Joined: 19 Jul 2011
Posts: 14
|
Its certainly something we're aware of and are looking at. If you redeploy an application then currently the monitoring settings need to be re-applied as with a fresh deployment.
This of course may or may not fix the OP's problem, but if you change a flow and redeploy, you can be caught out here. |
|
| Back to top |
|
|
| master_jack |
| Posted: Sat May 26, 2012 7:21 pm Post subject: Additional details |
|
|
Newbie
Joined: 22 May 2012
Posts: 4
|
My flow looks something like this.
In both the cases, monitoring is enabled for all terminals but events are not captured in the 'maroon' colored path.
However, the execution does occur in both the paths.
In case-2, the events are captured in the 'catch' path.
Thanks. |
|
| Back to top |
|
|
| kimbert |
| Posted: Mon May 28, 2012 2:07 am Post subject: |
|
|
Jedi Council
Joined: 29 Jul 2003
Posts: 5542
Location: Southampton
|
|
| Back to top |
|
|
| kash3338 |
| Posted: Mon May 28, 2012 9:47 pm Post subject: |
|
|
Shaman
Joined: 08 Feb 2009
Posts: 709
Location: Chennai, India
|
When we set the Event Unit of Work to Message Flow, the definition says,
| Quote: |
| The event, and all other events with this setting, are emitted only if the message flow commits its unit of work successfully |
What exactly does this mean when it says commits successfully? When I use a Throw node in the catch path of the input node and set the EVent Unit of work to Message Flow, the events in the catch path are not logged (as mentioned above by master_jack), but when I remove the throw node in the catch path, the events are logged.
Does that mean when I use the Throw node, the transaction is not complete? What is the difference here? |
|
| Back to top |
|
|
| kimbert |
| Posted: Mon May 28, 2012 11:33 pm Post subject: |
|
|
Jedi Council
Joined: 29 Jul 2003
Posts: 5542
Location: Southampton
|
I'm no expert in message flow error handling, but I think the product is behaving exactly as documented. The 'unit of work' or 'transaction' gets committed if there are no exceptions thrown on the main branch. The message is sent to the Catch terminal if there are exceptions thrown, and if there are no further exceptions then the UOW/transaction gets committed when the Catch branch completes. If you put in a Throw node you cause the UOW/transaction to fail and roll back.
Are you saying that the behaviour surprises you? |
|
| Back to top |
|
|
| kash3338 |
| Posted: Tue May 29, 2012 9:36 pm Post subject: |
|
|
Shaman
Joined: 08 Feb 2009
Posts: 709
Location: Chennai, India
|
| kimbert wrote: |
| Are you saying that the behaviour surprises you? |
This behaviour is not a surprise but when I thorw a exception in my catch block, it goes to the failure terminal and its handled there, then why is this transaction not committed? |
|
| Back to top |
|
|
| smdavies99 |
| Posted: Tue May 29, 2012 10:31 pm Post subject: |
|
|
Jedi Council
Joined: 10 Feb 2003
Posts: 6076
Location: Somewhere over the Rainbow this side of Never-never land.
|
in most cases when you have a failure in the middle of a transaction, it is rolled back and nothing is committed.
Throwing an exception causes a 'transaction rollback' or unwind and anything that has not been explicitly committed is undone.
I'd tend to concur with Kimbert in that the product is behaving as designed.
However, throwing an exception after you have already thrown one may lead to behaviour you might not anticipate. Throwing another exception (in the failure path) is not something that I have ever considered doing. all the error/exception handling scenarios I've worked on since V2.1 have not needed that sort of functionality.
There were one or two strange ones in V2.0.2 days but that might have been down to unfamiliararity with the product. One site even had a design mandate to connect ALL Catch and Failure terminals to the error handler. Rollback was unheard of.
_________________
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 |
|
|
| kimbert |
| Posted: Wed May 30, 2012 12:55 am Post subject: |
|
|
Jedi Council
Joined: 29 Jul 2003
Posts: 5542
Location: Southampton
|
In this topic: http://publib.boulder.ibm.com/infocenter/wmbhelp/v8r0m0/topic/com.ibm.etools.mft.doc/ac00410_.htm
it says:
| Quote: |
If you do not connect the Catch terminal of the input node, you can connect the Failure terminal and provide a fail flow to handle exceptions generated by the node. The fail flow is started immediately when an exception occurs in the node.
The fail flow is also started if an exception is generated beyond the MQInput node (in either out or catch flows), the message is transactional, and the reinstatement of the message on the input queue causes the backout count to reach the backout threshold.
The HTTPInput node does not propagate the message to the Failure terminal if an exception is generated beyond the node and you have not connected the Catch terminal. |
|
|
| Back to top |
|
|
|
|
