-
Notifications
You must be signed in to change notification settings - Fork 1.1k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
RemoteFileTemplate needlessly marks session dirty in case of no such file error #8745
Comments
I think we can come up with something like Let us know if you are will to contribute the fix: https://github.com/spring-projects/spring-integration/blob/main/CONTRIBUTING.adoc Thank you! |
Fixes spring-projects#8745 Not all errors caught in the `RemoteFileTemplate.execute()` are fatal to mark session as dirty and physically close the target session in the cache * Introduce a `RemoteFileTemplate.shouldMarkSessionAsDirty()` to consult with an exception if it is really a fatal error to close the session in the end. * Override `shouldMarkSessionAsDirty()` in the `RemoteFileTemplate` implementations to check statuses of respective protocol errors **Cherry-pick to `6.1.x` & `6.0.x`**
* GH-8745: Add RFT.shouldMarkSessionAsDirty() Fixes #8745 Not all errors caught in the `RemoteFileTemplate.execute()` are fatal to mark session as dirty and physically close the target session in the cache * Introduce a `RemoteFileTemplate.shouldMarkSessionAsDirty()` to consult with an exception if it is really a fatal error to close the session in the end. * Override `shouldMarkSessionAsDirty()` in the `RemoteFileTemplate` implementations to check statuses of respective protocol errors **Cherry-pick to `6.1.x` & `6.0.x`** * * Fix tests for pool interaction * * Fix language in Javadocs * Add more `not dirty` statuses to `SftpRemoteFileTemplate` & `SmbRemoteFileTemplate`
* GH-8745: Add RFT.shouldMarkSessionAsDirty() Fixes #8745 Not all errors caught in the `RemoteFileTemplate.execute()` are fatal to mark session as dirty and physically close the target session in the cache * Introduce a `RemoteFileTemplate.shouldMarkSessionAsDirty()` to consult with an exception if it is really a fatal error to close the session in the end. * Override `shouldMarkSessionAsDirty()` in the `RemoteFileTemplate` implementations to check statuses of respective protocol errors **Cherry-pick to `6.1.x` & `6.0.x`** * * Fix tests for pool interaction * * Fix language in Javadocs * Add more `not dirty` statuses to `SftpRemoteFileTemplate` & `SmbRemoteFileTemplate`
* GH-8745: Add RFT.shouldMarkSessionAsDirty() Fixes #8745 Not all errors caught in the `RemoteFileTemplate.execute()` are fatal to mark session as dirty and physically close the target session in the cache * Introduce a `RemoteFileTemplate.shouldMarkSessionAsDirty()` to consult with an exception if it is really a fatal error to close the session in the end. * Override `shouldMarkSessionAsDirty()` in the `RemoteFileTemplate` implementations to check statuses of respective protocol errors **Cherry-pick to `6.1.x` & `6.0.x`** * * Fix tests for pool interaction * * Fix language in Javadocs * Add more `not dirty` statuses to `SftpRemoteFileTemplate` & `SmbRemoteFileTemplate`
@pakorcz thank you for finding the source of the issue! |
In what version(s) of Spring Integration are you seeing this issue?
6.1.3
Describe the bug
The issue applies to all classes which extend
org.springframework.integration.file.remote.RemoteFileTemplate
. The description below usesSftpRemoteFileTemplate
fromspring-integration-sftp
as an example.RemoteFileTemplate::execute
method marks session dirty in case of any exception.It prevents session to be reused and makes
CachingSessionFactory
inefficient.As a result, too many sessions are created and SFTP server may reject new connections.
Certain exceptions, like
SftpConstants.SSH_FX_NO_SUCH_FILE
, should not cause session to be marked dirty.To Reproduce
DefaultSftpSessionFactory
to point to some valid SFTPCachingSessionFactory
SftpRemoteFileTemplate
to use createdCachingSessionFactory
SftpRemoteFileTemplate::list
method with some path that does not exist on the serverExpected behavior
Probably each class that extends
RemoteFileTemplate
should be able to define strategy for differentiating if an exception should mark session dirty.Workaround
Use
SftpRemoteFileTemplate::exists
before eachSftpRemoteFileTemplate::list
(calllist
only whenexists
returnstrue
)The text was updated successfully, but these errors were encountered: