Spring Boot 1.5.8兼容Spring Integration 5.x吗?4.x如何实现max-fetch-size?
Hey there! Let's tackle your questions one by one since you're working on a production-ready solution with tight deadlines.
Short answer: Not recommended, and it's likely to cause stability issues in production.
Spring Boot 1.5.x is built on Spring Framework 4.3.x, while Spring Integration 5.x requires Spring Framework 5.x as a minimum dependency. This version mismatch will lead to conflicting class definitions, missing methods, and unexpected runtime errors—things you definitely don't want in a production environment launching in March.
While you could technically force override the Spring Integration version in your pom.xml or build.gradle, this is an unsupported configuration. The Spring Boot team doesn't test this combination, so you'll be on your own if you run into bugs or compatibility problems. Given your production timeline, sticking to supported, tested versions is the safest bet.
Since you can't use Spring Integration 5.x, here's a reliable way to replicate the max-fetch-size behavior in 4.x:
Option 1: Extend the SftpPersistentAcceptOnceFileListFilter
The default filter tracks already processed files to avoid re-downloads. You can extend this filter to limit the number of unprocessed files that get downloaded in each polling cycle.
Here's a custom filter implementation:
import org.springframework.integration.file.filters.SftpPersistentAcceptOnceFileListFilter; import org.springframework.integration.metadata.MetadataStore; import java.io.File; import java.util.List; public class LimitedSftpPersistentAcceptOnceFileListFilter extends SftpPersistentAcceptOnceFileListFilter { private final int maxFetchSize; public LimitedSftpPersistentAcceptOnceFileListFilter(MetadataStore metadataStore, String prefix, int maxFetchSize) { super(metadataStore, prefix); this.maxFetchSize = maxFetchSize; } @Override public List<File> filterFiles(File[] files) { // First get all unprocessed files using the parent filter logic List<File> unprocessedFiles = super.filterFiles(files); // Limit to the max number of files we want to fetch if (unprocessedFiles.size() > maxFetchSize) { return unprocessedFiles.subList(0, maxFetchSize); } return unprocessedFiles; } }
Then configure this filter in your SFTP inbound adapter (Java configuration example):
@Bean public SftpInboundFileSynchronizer sftpInboundFileSynchronizer() { SftpInboundFileSynchronizer synchronizer = new SftpInboundFileSynchronizer(sftpSessionFactory()); synchronizer.setRemoteDirectory("/your/remote/sftp/path"); synchronizer.setDeleteRemoteFiles(false); // Adjust based on your needs // Use our custom filter to limit to 10 files per fetch synchronizer.setFilter(new LimitedSftpPersistentAcceptOnceFileListFilter(metadataStore(), "sftp-file-tracker-", 10)); return synchronizer; } @Bean public MetadataStore metadataStore() { // Use a persistent store (like Redis, JDBC) for production to avoid losing track of processed files on restart // For testing, you can use a SimpleMetadataStore, but it's in-memory return new SimpleMetadataStore(); }
Option 2: Combine with a Poller and Batch Processing
If you need more control over processing, you can adjust the poller's frequency and use a batch message handler. However, the custom filter approach is more direct because it limits the number of files downloaded upfront—just like max-fetch-size does in Spring Integration 5.x.
Key Notes for Production
- Use a persistent
MetadataStore(like JDBC or Redis) instead of the in-memorySimpleMetadataStore—this ensures you don't re-process files if your application restarts. - Test the filter thoroughly with your SFTP server to make sure it handles edge cases (like empty directories, more files than the limit, etc.).
This solution is stable, compatible with Spring Boot 1.5.8 and Spring Integration 4.x, and will give you the exact control you need over the number of files downloaded per cycle.
内容的提问来源于stack exchange,提问作者user509755

