You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I am not sure if this has been addressed already but could we have a configuration which would skip caching for jars in JarUrlConnection.java (basically mimic the behavior which was present in spring.boot.loader 3.1.x for windows server 2016) for future spring boot versions.
The question on Stack Overflow speculates that the cache "might be causing file locking in windows server 2016". File locking, if it resulted in contention, could slow things down, but I'm not sure that it would appear as increased CPU time in org.springframework.boot.loader.net.protocol.jar.JarFileUrlKey.get(URL) which is what the profiler seems to show.
Can you please explain in more detail why you believe that the cache is the cause of the problem?
At this point it's just a speculation but when I tried running the executable with an earlier version of spring boot i.e 3.1.x, this issue did not occur for me whereas in 3.3.x in which we currently are running the application we are facing it.
On comparing the source code for both the jars, it seems that the functionality to cache in JarFileUrlKey is not present in 3.1.x. but present in 3.3.x. So based on the profiler results I assumed the caching mechanism might be causing an issue.
This is very env specific. We are only seeing this in windows server 2016.
Unfortunately, we can't justify making a change for an env-specific problem when the cause is just speculation. Perhaps you could try making the change locally and gather some data about the performance with and without the cache?
If you would like us to look at this issue, please provide the requested information. If the information is not provided within the next 7 days this issue will be closed.
The classic loader won't be around forever (it will probably be removed in 4.0) so we'd still welcome some performance data if you have the time to gather it.
Activity
wilkinsona commentedon Jun 4, 2025
Thanks for the suggestion.
The question on Stack Overflow speculates that the cache "might be causing file locking in windows server 2016". File locking, if it resulted in contention, could slow things down, but I'm not sure that it would appear as increased CPU time in org.springframework.boot.loader.net.protocol.jar.JarFileUrlKey.get(URL) which is what the profiler seems to show.
Can you please explain in more detail why you believe that the cache is the cause of the problem?
Shashwat7390 commentedon Jun 4, 2025
Hello,
At this point it's just a speculation but when I tried running the executable with an earlier version of spring boot i.e 3.1.x, this issue did not occur for me whereas in 3.3.x in which we currently are running the application we are facing it.
On comparing the source code for both the jars, it seems that the functionality to cache in JarFileUrlKey is not present in 3.1.x. but present in 3.3.x. So based on the profiler results I assumed the caching mechanism might be causing an issue.
This is very env specific. We are only seeing this in windows server 2016.
wilkinsona commentedon Jun 4, 2025
Unfortunately, we can't justify making a change for an env-specific problem when the cause is just speculation. Perhaps you could try making the change locally and gather some data about the performance with and without the cache?
spring-projects-issues commentedon Jun 11, 2025
If you would like us to look at this issue, please provide the requested information. If the information is not provided within the next 7 days this issue will be closed.
Shashwat7390 commentedon Jun 13, 2025
Hello,
So basically after disabling the cache locally, I found that the nested jar classloading was taking quite a bit of time.
After digging through some spring forums, I came across https://github.com/spring-projects/spring-boot/wiki/Spring-Boot-3.2-Release-Notes#nested-jar-support.
After setting loaderimplementation to CLASSIC, that did the trick and now application is working as expected.
Thanks.
wilkinsona commentedon Jun 13, 2025
The classic loader won't be around forever (it will probably be removed in 4.0) so we'd still welcome some performance data if you have the time to gather it.
4 remaining items