| Author |
Message
|
| gin123 |
 Posted: Tue May 06, 2014 10:43 am Post subject: file input node |
 |
|
Newbie
Joined: 16 Apr 2014
Posts: 4
|
The file input node in my solution appears to behave differently in my local Windows development environment, compared to the AIX deployed environment so I'm having problems debugging an issue.
In the AIX deployed environment, the Failure output node sometimes gets called. After it occurs, the application 'freezes' and no further files get picked up. (MB needs to be restarted)
My questions:
1. When the 'Failure' output node is called, will the 'End of File' output node still get called?
2. What's the difference between the 'Catch' output node, and the 'Failure' one? That is, why would the 'Failure' node get called instead of the 'Catch'?
3. Can MB still continue processing additional files after the 'Failure' node is called? Can I programmatically reset anything to have it continue?
Thanks in advance. |
|
| Back to top |
|
 |
| Vitor |
| Posted: Tue May 06, 2014 11:05 am Post subject: Re: file input node |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| gin123 wrote: |
| 1. When the 'Failure' output node is called, will the 'End of File' output node still get called? |
No.
| gin123 wrote: |
| 2. What's the difference between the 'Catch' output node, and the 'Failure' one? That is, why would the 'Failure' node get called instead of the 'Catch'? |
See here
| gin123 wrote: |
| 3. Can MB still continue processing additional files after the 'Failure' node is called? Can I programmatically reset anything to have it continue? |
Yes it can, and if it's not it's because of something you're doing. By default the flow will traverse the failure path, move the file to mqsibackout and end. At this point it will start polling for the next file to process. For it to be doing what you're describing, the failure path is not ending properly.
There's nothing to "reset".
I suspect the difference you're seeing reflects the difference in the way Windows & AIX handle files.
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| fjb_saper |
| Posted: Tue May 06, 2014 7:40 pm Post subject: Re: file input node |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20756
Location: LI,NY
|
| Vitor wrote: |
I suspect the difference you're seeing reflects the difference in the way Windows & AIX handle files. |
Or possibly due to specific content of the file...That could make it take a path you might not have tested coverage for... I guess that you did not ftp the file to windows to test it? 
_________________
MQ & Broker admin |
|
| Back to top |
|
|
| Tibor |
| Posted: Wed May 07, 2014 5:29 am Post subject: |
|
|
Grand Master
Joined: 20 May 2001
Posts: 1033
Location: Hungary
|
| Have you checked the syslog for message broker related entries? Our brokers works on AIX platforms and I don't remember such an errors / symptoms. |
|
| Back to top |
|
|
| Esa |
| Posted: Wed May 07, 2014 5:35 am Post subject: Re: file input node |
|
|
Grand Master
Joined: 22 May 2008
Posts: 1387
Location: Finland
|
| gin123 wrote: |
| so I'm having problems debugging an issue. |
So this happens when you have a debugger attached to the execution group? |
|
| Back to top |
|
|
| Vitor |
| Posted: Wed May 07, 2014 5:56 am Post subject: Re: file input node |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| Esa wrote: |
| gin123 wrote: |
| so I'm having problems debugging an issue. |
So this happens when you have a debugger attached to the execution group? |
Which would (for example) cause the application to freeze until the debugger is released 
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
|
|
