[#SFTP-15] Add keepFileOnError parameter

SFTP Transport Project

Add keepFileOnError parameter

Created: 03/Dec/09 06:11 AM Updated: 07/Dec/09 03:49 AM

Component/s:

Code

Affects Version/s:

2.2.1-RC1

Fix Version/s:

2.2.1-RC2

Time Tracking:

Not Specified

Labels:
User impact:	Low
Similar Issues:

Description

« Hide

In the 2.2.x branch we did a change that when an exception occurs in the transport we didn't delete the file.

This broke backward compatibility. Another problem is that other transports don't work this way.
The third issue is that this functionality only worked when both the inbound and outbound endpoints was using the sftp-transport.

The suggestion is to add a 'keepFileOnError' paramater to the outbound endpoint. When the value is true
we will ensure that the file is not deleted if an exception is thrown. The documentation has to be clear about
the limitation about sftp-->sftp as well.

All

Comments

Work Log

Change History

Transitions

FishEye

Sort Order:

[ Permlink | « Hide ]

Magnus Larsson added a comment - 03/Dec/09 06:22 AM

Can you start with producing a testcase that demonstrates the problem, i.e. fails with the current implementation?

I think that could make the issues clearer to understand.

[ Permlink | « Hide ]

Lennart Häggkvist added a comment - 03/Dec/09 06:46 AM

This is the description from the File-Transport:
"Description : If set to true (the default), it will cause the file to be deleted once it is read. If streaming is turned on, this occurs when the InputStream for the file is closed. Otherwise the file will be read into memory and deleted immediately."

That means that the file will always be deleted (when the stream is closed).

Also, if you use an Exception Strategy that handle the message if an error occurs you got the problem that the file is not deleted, and thus the file will be resent in the next poll()...

So, I could write a test case for
#1 - Copying files using File-Transport to Sftp-Transport (and forcing an exception)
#2 - Using Sftp-transport -> Sftp-transport together with an exception strategy

The problem is that I think that could take more time than I currenty have.

My suggestion/patch is only about ensure that the transport works as earlier versions and that the new functionality is optional, thus not enforcing this on users running the old transport as well as confusing users that thinks that files never will be deleted if an exception occurs (independent on which transport they use on the inbound endpoint)

[ Permlink | « Hide ]

Lennart Häggkvist added a comment - 04/Dec/09 12:31 AM

The code is now committed.

The default for the attribute keepFileOnError is false to ensure backward compatibility as a default value.
However, I don't see any problems setting the default value to true?

[ Permlink | « Hide ]

Lennart Häggkvist added a comment - 07/Dec/09 03:34 AM

Changed the default value to true after discussion with Magnus