| |
|
RSS Feed - WebSphere MQ Support
|
RSS Feed - Message Broker Support
|
  |
|
| Managing Errors in the Input Node |
« View previous topic :: View next topic » |
| Author |
Message
|
| shashivarungupta |
 Posted: Sun Jan 11, 2015 3:30 pm Post subject: Managing Errors in the Input Node |
 |
|
Grand Master
Joined: 24 Feb 2009
Posts: 1343
Location: Floating in space on a round rock.
|
Hi,
As per the description in the following URL, the third point says... "* Any internal exceptions that occur in the node after the message has been propagated to the Out terminal cause a rollback of the transaction. This situation is rare but could happen for some input nodes."
Which are those 'some' input nodes, if you've come across of this scenario. Kindly share/suggest.
Thanks. 
_________________
*Life will beat you down, you need to decide to fight back or leave it. |
|
| Back to top |
|
 |
| fjb_saper |
| Posted: Sun Jan 11, 2015 7:51 pm Post subject: Re: Managing Errors in the Input Node |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20756
Location: LI,NY
|
| shashivarungupta wrote: |
Hi,
As per the description in the following URL, the third point says... "* Any internal exceptions that occur in the node after the message has been propagated to the Out terminal cause a rollback of the transaction. This situation is rare but could happen for some input nodes."
Which are those 'some' input nodes, if you've come across of this scenario. Kindly share/suggest.
Thanks. |
Think about a parsing error when doing parsing on demand...
_________________
MQ & Broker admin |
|
| Back to top |
|
|
| kimbert |
| Posted: Mon Jan 12, 2015 1:20 am Post subject: |
|
|
Jedi Council
Joined: 29 Jul 2003
Posts: 5542
Location: Southampton
|
The key phrase is 'in the node'. Parsing errors that occur in a downstream node would not be 'internal exceptions that occur in the node'.
I think this is simply saying that some nodes need to do some cleanup after propagating the message to the Out terminal. If that cleanup code goes wrong then the transaction is rolled back. Obviously, this only applies if the node is one of the nodes that supports transactional behaviour.
_________________
Before you criticize someone, walk a mile in their shoes. That way you're a mile away, and you have their shoes too. |
|
| Back to top |
|
|
| shashivarungupta |
| Posted: Tue Jan 13, 2015 12:26 pm Post subject: |
|
|
Grand Master
Joined: 24 Feb 2009
Posts: 1343
Location: Floating in space on a round rock.
|
| kimbert wrote: |
The key phrase is 'in the node'. Parsing errors that occur in a downstream node would not be 'internal exceptions that occur in the node'. |
IBM Manaul says, Input Node (as MQInput) detects an internal error in following cases:
1. Parser can cause parsing/validation error, is treated as an internal error.
2. Warning on an mqget call
3. When BOT is reached.
So, I think above point is still valid.
| kimbert wrote: |
I think this is simply saying that some nodes need to do some cleanup after propagating the message to the Out terminal. If that cleanup code goes wrong then the transaction is rolled back. Obviously, this only applies if the node is one of the nodes that supports transactional behaviour. |
If I've MQInput Node (that supports transactional behaviour) then what cleanup are you talking about , 'after' propagating msg to Out terminal ?
Is that clean up conditional ?
_________________
*Life will beat you down, you need to decide to fight back or leave it. |
|
| Back to top |
|
|
| kimbert |
| Posted: Tue Jan 13, 2015 1:34 pm Post subject: |
|
|
Jedi Council
Joined: 29 Jul 2003
Posts: 5542
Location: Southampton
|
| Quote: |
IBM Manaul says, Input Node (as MQInput) detects an internal error in following cases:
1. Parser can cause parsing/validation error, is treated as an internal error.
2. Warning on an mqget call
3. When BOT is reached. |
That does not sound correct.
The phrase 'internal error' has a very specific meaning. It is an unexpected condition that cannot be handed using a program's normal error handling strategies. Running out of memory or disk space would be an 'internal error'.
A parsing or validation error is definitely *not* an internal error. It is a normal 'recoverable exception', and is handled as described here:
http://www-01.ibm.com/support/knowledgecenter/SSKM8N_8.0.0/com.ibm.etools.mft.doc/bz90325_.htm
According to that definition, a parsing error that happens in the MQInput node is not an 'internal error'. It is a normal exception that just happened to occur in the node. I would expect it to be routed to the Failure terminal first. Then, if the Failure terminal is not wired up it will go to the Catch terminal - where it can be treated just like any other message flow exception.
| Quote: |
If I've MQInput Node (that supports transactional behaviour) then what cleanup are you talking about , 'after' propagating msg to Out terminal ?
Is that clean up conditional ? |
I'm talking about the IBM code that implements the MQInput node. If some 'internal error' happens in that code after the node has propagated the message to the 'out' terminal, then the transaction will be rolled back.
I think that is good, safe behaviour. The node has almost finished. The entire flow has executed, and control has returned to the MQInput node.
Then something unexpected happens in code that implements the node.
It would be wrong to treat it like a normal message flow exception because the flow will have completed all of its processing already. Asking the message flow author to cope with the error would be unreasonable.
So it seems right that the entire transaction should be rolled back.
_________________
Before you criticize someone, walk a mile in their shoes. That way you're a mile away, and you have their shoes too. |
|
| Back to top |
|
|
| shashivarungupta |
| Posted: Tue Jan 13, 2015 3:37 pm Post subject: |
|
|
Grand Master
Joined: 24 Feb 2009
Posts: 1343
Location: Floating in space on a round rock.
|
| kimbert wrote: |
| Quote: |
IBM Manaul says, Input Node (as MQInput) detects an internal error in following cases:
1. Parser can cause parsing/validation error, is treated as an internal error.
2. Warning on an mqget call
3. When BOT is reached. |
That does not sound correct. |
| Quote: |
As per IBM InfoCenter [v8]:
The MQInput node detects an internal error in the following situations:
* An exception occurs when the associated message parser is initialized. If the Parse timing property is set to Immediate or Complete, the parser parses the input message after initialization. This parsing can cause a parsing or validation error, which is treated as an internal error.
* A warning is received on an MQGET call.
* The backout threshold is reached when the message is rolled back to the input queue. |
I think, above statement about 'internal errors' has got more indepth meaning than what it seems. And thanks for bringing it up. 
| kimbert wrote: |
| The phrase 'internal error' has a very specific meaning. It is an unexpected condition that cannot be handed using a program's normal error handling strategies. Running out of memory or disk space would be an 'internal error'. |
Agree., and there could be many more such 'internal errors' which are beyond the control of message broker product itself and might change the normal behaviour of its functional product code, I think, and those are handled by product code itself as 'internal error(s)'.
| kimbert wrote: |
| Quote: |
If I've MQInput Node (that supports transactional behaviour) then what cleanup are you talking about , 'after' propagating msg to Out terminal ?
Is that clean up conditional ? |
I'm talking about the IBM code that implements the MQInput node. If some 'internal error' happens in that code after the node has propagated the message to the 'out' terminal, then the transaction will be rolled back.
I think that is good, safe behaviour. The node has almost finished. The entire flow has executed, and control has returned to the MQInput node.
Then something unexpected happens in code that implements the node.
It would be wrong to treat it like a normal message flow exception because the flow will have completed all of its processing already. Asking the message flow author to cope with the error would be unreasonable.
So it seems right that the entire transaction should be rolled back. |
I agree about that, that it doesn't seem reasonable to handle the Product Code Issues (as you've mentioned 'internal error') at the Application Code Level.
Keeping in mind that 'internal error' can occur 'before/after' the node has propagated the message down the stream.
Thanks for clarification.
_________________
*Life will beat you down, you need to decide to fight back or leave it. |
|
| Back to top |
|
|
|
|
|
| |
|
Page 1 of 1 |
|
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
|
|
|
|
