| |
|
RSS Feed - WebSphere MQ Support
|
RSS Feed - Message Broker Support
|
  |
|
| Fileinput node FTP errors |
« View previous topic :: View next topic » |
| Author |
Message
|
| pavan15 |
 Posted: Mon Oct 21, 2013 2:15 pm Post subject: Fileinput node FTP errors |
 |
|
Novice
Joined: 22 Dec 2010
Posts: 10
|
Hello All,
I have a FileInput Node in a Message flow which scans Remote Windows FTP Server and it is deployed in two different Execution groups in two different Brokers. These Two Flows are remotely reading files from same remote directory successfully (without any exceptions in catch terminal) and sending them to MQOutput. This message Flow in bothe the Brokers has FTP scan Delay property set to 60 seconds and looks for same file name pattern on remote server. The Ftp crentials used by Message broker to connect to Ftp server has remote File delete rights and deleteting the files succefully after ftp transfer.But syslogs on both servers are piling up with below BIP3385 Errors. Please let us know your thoughts for these errors. Thanks in Advance.
| Code: |
| Oct 21 10:55:24 wdcamqp06 user:err|error WebSphere Broker v8001[13500422]: (BKUNXD.eg1)[7738]BIP3385E: File node 'File Input' in message flow 'TEST'. Unexpected I/O exception occurred in communication with FTP server 'FtpService[svwv1,CWD '\Distribution\ack']'. I/O exception text is 'Could not delete file :'SERV_FROM_MAC_Ack_105514432.xml''. : BKUNXD.2b64f58f-4001-0000-0080-bf5d4b863a0f: /build/slot1/S800_P/src/DataFlowEngine/NativeTrace/ImbNativeTrace.cpp: 739: com.ibm.broker.nodes.filenodes.ComIbmFileInputNode.transferFromRemoteServer(): : |
|
|
| Back to top |
|
 |
| Esa |
| Posted: Mon Oct 21, 2013 9:58 pm Post subject: |
|
|
Grand Master
Joined: 22 May 2008
Posts: 1387
Location: Finland
|
A file can be simultaneously read by two ftp clients, but only one of them can delete it. The second one will get an exception like that, I guess.
Can you examine the messages in the output queues to determine if some files get processed by both flow instances. There is no locking that would prevent that, you know.
But why don't the flows catch Exceptions? Could it be that remote files are deleted only after the flow has committed? Sounds unbelievable, that would be a defect. On the other hand, it's probably not a defect if the product doesn't support bad design...
If your design is for load balancing or scaling purposes, it would be better to have only one flow instance (at the time) listening to the remote FTP server and distributing the files to two processing flows using MQ techniques like cluster queues. |
|
| Back to top |
|
|
| Esa |
| Posted: Mon Oct 21, 2013 10:45 pm Post subject: |
|
|
Grand Master
Joined: 22 May 2008
Posts: 1387
Location: Finland
|
| Esa wrote: |
| The second one will get an exception like that, I guess. |
As the FTP server runs on Windows, it could also be the first client thread trying to delete the file that gets the exception. The file cannot be deleted because it's still open by the other client.
Anyhow, you should consider changing your design. |
|
| Back to top |
|
|
| pavan15 |
| Posted: Tue Oct 22, 2013 5:43 am Post subject: |
|
|
Novice
Joined: 22 Dec 2010
Posts: 10
|
Thanks for your thoughts Esa.
Duplicate messages are not reaching Mqoutput. And as per usertrace Remote files are being deleted immediately after file is transferred to local mqsitransitin directory and before ftp session is closed.
probably in my case as scan delay is 60 seconds in fileoutput node we may have deployed in second execution group at the same time when Fileoutput node in first execution group started ftp session after sleeping for 60 seconds and thereafter they both are opening ftp sessions at the same time and having this problem.
Will try to increase ftp scan delay property and observe. Thanks again. |
|
| Back to top |
|
|
| Esa |
| Posted: Tue Oct 22, 2013 9:52 pm Post subject: |
|
|
Grand Master
Joined: 22 May 2008
Posts: 1387
Location: Finland
|
| pavan15 wrote: |
Duplicate messages are not reaching Mqoutput. And as per usertrace Remote files are being deleted immediately after file is transferred to local mqsitransitin directory and before ftp session is closed.
|
Oh yes, the error for the duplicate message happens before the actual flow instance is started. That's why the flow doesn't catch an exception!
Built-in support for scaling FileInput flows over multiple brokers, nice!
If you haven't already done it, you could override the scan delay in the bar files giving for example 59 seconds for the first deployment and 61 for the other. That could make the flows collide less frequently.
I think the entries in system log are harmless in your case, but of course you would like to get rid of them. |
|
| 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
|
|
|
|
