Change in Jar usecache behavior with Spring 6.1.x causing java.lang.IllegalStateException: zip file closed

[rahulsh1]

We use the PathMatchingResourcePatternResolver outside of Spring to discover resources on the classpath, as it provides significant performance benefits as compared to anything else we came up with.

One such class looks for resources using a ForkJoinPool to scan for multiple patterns in the classpath using PathMatchingResourcePatternResolver. This worked fine with Spring 5.3.x.
Post migration to Spring 6.1.x, we started seeing a random java.lang.IllegalStateException: zip file closed on some of the invocations

After looking at the implementation differences between the 5.3.x and 6.1.x, it appears a change was done to remove the call to ResourceUtils.useCachesIfNecessary(jarCon);

The 5.3.x implementation sets the useCache on the JarConnection as false (since there is no JNLP) while there is no such thing happening with 6.1.x.

// 5.3.x
public static void useCachesIfNecessary(URLConnection con) {
  con.setUseCaches(con.getClass().getSimpleName().startsWith("JNLP"));
}

This appears to be related to JDK-6947916 where inconsistent values of the useCache flag may result in this behavior for a multi-threaded invocation.

With Spring 5.3.x, this was explicitly set to be false while now with Spring 6.1.x, that guarantee does not exist resulting in the race condition and random "zip file closed" exceptions.

[jhoeller]

This is actually a 6.1.x regression. That said, please note that PathMatchingResourcePatternResolver got heavily revised in 6.2 for internal caching. It'd be great if you could give 6.2.5 a try and see whether the problem still remains against that caching approach.

Generally wondering, is anything holding you back from upgrading to 6.2.x directly? At this point, it's the recommended target for 5.3.x migrations.

[jhoeller]

We can make jar caching configurable through a setUseCaches method on PathMatchingResourcePatternResolver. On 6.2, this affects JarURLConnection caching as well as our local caching in the resolver, whereas on 6.1.19 it only affects JarURLConnection. The default stays the same but you may set it to false if that turns out to be necessary in your scenario.

[jhoeller]

@rahulsh1 this setUseCaches(false) option on PathMatchingResourcePatternResolver is available in the latest 6.2.6 and 6.1.19 snapshots now. Please give it a try at your earliest convenience!

[rahulsh1]

thanks @jhoeller. Will try it out this week and report back but I think the fix should get back the same behavior as 5.3.

Will start with Spring 6.2 in a couple of weeks.
Good to know that PathMatchingResourcePatternResolver got heavily revised in 6.2 with caching support.

In 2018, I implemented a custom cached version of PathMatchingResourcePatternResolver and submitted it as PR-1981, which provided performance improvements through caching. It might be time to consider retiring the home-grown version in favor of the enhanced version in 6.2.