| Author |
Message
|
| Yanghui |
 Posted: Tue Oct 01, 2002 6:59 am Post subject: Stranage reaction of msgflow |
 |
|
Disciple
Joined: 08 May 2002
Posts: 151
Location: Dublin, Ireland
|
Hi,
I don't understand why msgflow reacts like this way. For error handling testing, we deliberatly put an invalid XML on the queue. The XML msg only has nothing else but one line
<?xml version="1.0" encoding="UTF-8"?>.
I thought msgflow would reject it and throw exception to either failure or catch terminal of my input node but the reality is that msgflow is confused by this invalid xml and hang on there forever.
Can anybody explain this to me? Thanks a lot.
-Yanghui |
|
| Back to top |
|
 |
| Yanghui |
| Posted: Tue Oct 01, 2002 7:44 am Post subject: |
|
|
Disciple
Joined: 08 May 2002
Posts: 151
Location: Dublin, Ireland
|
Warning!!
Please don't try this if you are not allowed to reboot the machine on which your broker resides.
I just found that sometimes broker wouldn't stop hanging even after I restarted the broker process. System reboot did stop broker hanging but I really don't understand this simple one line msg can upset broker so much.
-Yanghui |
|
| Back to top |
|
|
| lung |
| Posted: Tue Oct 01, 2002 4:47 pm Post subject: |
|
|
Master
Joined: 27 Aug 2002
Posts: 291
Location: Malaysia
|
Yanghui,
When a message cannot be parsed by the input node, it will be thrown back into the input queue. The input node will then again pick up a message from the queue, which in this case, is the SAME message that cannot be parsed just now.
A message will only go through the failure or catch terminals if exception occurs AFTER it was parsed.
To counter this problem, define a backout queue for your input queue and make sure the backout threshold is NOT equal to 0.
_________________
lung |
|
| Back to top |
|
|
| Yanghui |
| Posted: Wed Oct 02, 2002 6:42 am Post subject: |
|
|
Disciple
Joined: 08 May 2002
Posts: 151
Location: Dublin, Ireland
|
Lung,
Thanks for your reply. It's very helpful indeed. My problem is partial solved. However I got another problem of using backout q. I setup the backout threshold as 1. The first invalid message was moved to my backout queue successfully but it wouldn't work on the rest invadid messages which means my msgflow would still hang on there after the second invalid message arrived. Frankly, I don't understand. Do you know why? Looking forward to any idea or suggestions.
Many thanks again
-Yanghui |
|
| Back to top |
|
|
| lung |
| Posted: Wed Oct 02, 2002 4:41 pm Post subject: |
|
|
Master
Joined: 27 Aug 2002
Posts: 291
Location: Malaysia
|
Honestly speaking, I haven't really try out the backout queue method myself But if the first invalid message is successfully routed to the backout queue, then the second one should go there as well, shouldn't it? I'm as stumped as you are... Maybe someone else out there can help us out?
_________________
lung |
|
| Back to top |
|
|
| tchagan |
| Posted: Fri Oct 04, 2002 4:31 am Post subject: |
|
|
Apprentice
Joined: 10 Feb 2002
Posts: 31
|
Sorry Lung, but you're wrong about the message only being sent to the failure terminal after it is parsed. If a message fails because it cannot be parsed then it will go to the failure terminal of the MQInput node. If the failure terminal is not connected to anything i.e. an error queue, then the message will be backed out. It is because in this case that the failure terminal has not been connected to an MQOutput node that the message is backing out then being retried again and again. I would suggest to Yanghui that the MQInput node failure terminal be connected to some error processing flow that ends in an MQOutput node in order for the invalid message to be processed properly i.e. not backed out.
The catch terminal on the MQInput node is used when an error occurs after the message has been parsed and propagated onwards from the MQInput node.
cheers
Terry |
|
| Back to top |
|
|
| lung |
| Posted: Sun Oct 06, 2002 5:11 pm Post subject: |
|
|
Master
Joined: 27 Aug 2002
Posts: 291
Location: Malaysia
|
Terry,
The invalid message should end up to the failure terminal connection, but somehow we have tried this and the message will somehow be put back to the input queue. (as mentioned in Yanghui's first post)
So I assume that the failure terminal only works if the message is first parsed successfully by the input node
_________________
lung |
|
| Back to top |
|
|
| tchagan |
| Posted: Mon Oct 07, 2002 1:19 am Post subject: |
|
|
Apprentice
Joined: 10 Feb 2002
Posts: 31
|
Lung,
I've now had time to have a closer look at this in my test flow and the message is parsed. I would suggest that whatever is being carried out on the message after the MQInput node is causing an error and that the catch terminal of the MQInput node should be attached to an error processing flow that results in the message being output to an error queue rather than backed out.
A an output trace of the message going through my flow shows :
(0x1000010)XML = (
(0x5000018)XML = (
(0x6000011) = '1.0'
(0x6000012) = 'UTF-8'
)
)
which proves that the message has been parsed successfully.
You should probably look at what action is being carried out on the message to determine why and error is being causes. Also look at the broker log file which should give an indication of the error.
Terry |
|
| Back to top |
|
|
|
|
