Avoid file leak in JavaSPIExtensionLoader #637
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This is the same that was already done for RemoteExtensionLoader in #502: when running the test suite for https://github.com/arquillian/arquillian-extension-warp with the Glassfish profile (Glassfish 7.0.18), on windows there are file leaks that cause every test to take 20 seconds. Reason: Glassfish cannnot delete "arquillian-core.jar" on undeploy.
Using File Leak Detector, I found that org.jboss.arquillian.container.test.impl.RemoteExtensionLoader is the culprit for this leak:
URL.openStream
creates ajava.net.JarConnection
that caches opened files by default.As those files are accessed only once in Arquillian, there is no performance reason to cache them.
This pull request switches off caching.
WildFly is not affected by this problem because of the underlying VFS implementation. But GlassFish accesses the files directly.
For the archive: this is the stack trace that "File Leak Detector" reports:
In case someone wants to reproduce it: you first need my pull request for Weld (weld/core#3069) where something similar happened. After replacing the fixed Weld version, the issue from this pull request is reported.
And if both fixes are applied, the jars are no longer locked an can be deleted on undeploy.