英文:
CachingSessionFactory setPoolSize() takes much longer after upgrading spring boot from 2.2.1.RELEASE to 2.3.1.Release
问题
在我们的一个服务中，我们使用Spring集成框架将一些文件发送到FTP服务器。为此，我们以以下方式创建了一个CachingSessionFactory：
SessionFactory<?> factory = getSessionFactory(properties);
CachingSessionFactory cachingSessionFactory = new CachingSessionFactory<>(factory);
cachingSessionFactory.setSessionWaitTimeout(properties.getTimeout());
cachingSessionFactory.setPoolSize(5);
createDirectories(cachingSessionFactory, properties);
"properties" 是我们注入的一些@ConfigurationProperties，由我们创建。"getSessionFactory()" 也是由我们编写的，但我不确定这是否相关。
在我们从Spring Boot 2.2.1.Release升级到2.3.1.Release之后，服务启动时出现了巨大的性能损失。
看起来在设置池大小时存在问题，但我无法确定是什么问题。调试时，我发现进程在"setPoolSize(5)" 步骤中永远挂起。
英文:
In one of our services, we use spring integration framework to send some files to an FTP server. For that, we create a CachingSessionFactory in the following way
SessionFactory<?> factory = getSessionFactory(properties);
CachingSessionFactory cachingSessionFactory = new CachingSessionFactory<>(factory);
cachingSessionFactory.setSessionWaitTimeout(properties.getTimeout());
cachingSessionFactory.setPoolSize(5);
createDirectories(cachingSessionFactory, properties);
properties are some @ConfigurationProperties that we inject and was created by us. GetSessionFactory() is also done by us, but I'm not sure it this is relevant.
After we updated from spring boot 2.2.1.Release to 2.3.1.Release we have a huge performance penalty on service startup.
It looks like there is an issue with setting the pool size, but I cannot figure out what it is. When debugging, I see that the process hangs forever in the setPoolSize(5) step.
答案1
得分: 1
你可以尝试使用 DefaultFtpSessionFactory 替代 CachingSessionFactory。
DefaultFtpSessionFactory 不需要使用该池来工作。
英文:
You may try using - DefaultFtpSessionFactory instead of CachingSessionFactory
DefaultFtpSessionFactory doesn't need that pool to work.
答案2
得分: 1
我稍微深入研究了底层的类，发现 setPoolSize() 的负担比预期要重。特别是，它需要获取一些锁，这在我的情况下似乎导致了性能损耗。我没有找到实际的根本原因，但我有一个方便的方法来克服这个问题，那就是通过构造函数直接设置池的大小。通过这样做，它会被正确地创建，并且不需要对现有的池进行任何混乱操作。这行代码起了作用：
CachingSessionFactory cachingSessionFactory = new CachingSessionFactory<>(factory, 5);
英文:
I digged a little into the underlying classes and found out that the setPoolSize() is heavier than expected. Especially, it needs to acquire some locking which, in my case, seems to cause the performance penalty. I didn't find the actual root cause, but I have a convenient way to overcome the issue by setting the pool size directly via the constructor. By that, it is created correctly and no messing with the existing one is needed. This line did the trick
CachingSessionFactory cachingSessionFactory = new CachingSessionFactory<>(factory,5);
通过集体智慧和协作来改善编程学习和解决问题的方式。致力于成为全球开发者共同参与的知识库，让每个人都能够通过互相帮助和分享经验来进步。
评论