| |
|
RSS Feed - WebSphere MQ Support
|
RSS Feed - Message Broker Support
|
  |
|
| FileInput Node Retry |
« View previous topic :: View next topic » |
| Author |
Message
|
| smithamd |
 Posted: Tue Aug 18, 2015 11:21 am Post subject: FileInput Node Retry |
 |
|
Newbie
Joined: 18 Aug 2015
Posts: 7
|
Hello,
We have a message flow that reads files which contains multiple messages with base 64 encoded pdf's. As of now we have set the Retry mechanism to Failure and move to mqsibackout folder. Since the messages are huge , some times the file reading fails middle of the file and the whole file moves to mqsibackout folder without showing any errors in the logs. We then have to manually find the message it failed on and resend the rest of them which goes through fine.
We were thinking of using the "Retry mecahnism" on input node to short retry and set an interval of few minutes , which might help us avoid the manual intervention. My question is will the retry mechansim send the whole file again or just start from the failed message ? We do not want to send through the messages that were already sent in case of a failure.
Thanks. |
|
| Back to top |
|
 |
| Vitor |
| Posted: Tue Aug 18, 2015 11:50 am Post subject: Re: FileInput Node Retry |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| smithamd wrote: |
| My question is will the retry mechansim send the whole file again or just start from the failed message ? |
The FileInput node is not transactional; it will start from the start of the file again.
| smithamd wrote: |
| We do not want to send through the messages that were already sent in case of a failure. |
Then you need to design for that. Options include but are not limited to:
- Shredding the file into individual PDFs with one flow, and feeding those to your existing flow
- Obtaining some kind of identifier from the decoded PDF and storing the identifiers somewhere so that they're not processed the next time through.
Best of all, try fixing this:
| smithamd wrote: |
| Since the messages are huge , some times the file reading fails middle of the file |
If by "huge" you mean "so colossal they run the server out of memory" then either add more memory or change to a streaming parser. If you mean "big enough that the I/O controller on our server chokes" then get a new I/O controller (or a new server). If you don't mean that, what do you mean? How huge is huge? What exception do the records fail with?
The FileInput node should handle any realistic size of message without failing.
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| 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
|
|
|
|
