commons-vfs
commons-vfs copied to clipboard
VFS-824 HttpFileSystem free Unused Resources lead to HttpClient Conn…
…ection Pool Shutdown
https://issues.apache.org/jira/browse/VFS-824
How about the http5 file provider?
Hello @destroydestiny Thank for your PR. Please see my scattered comments.
How about the http5 file provider?
Http, http4, http5 provider has the same problem
You must have not run a local build with the default Maven goal (mvn
):
[ERROR] src/main/java/org/apache/commons/vfs2/provider/AbstractFileProvider.java:[19,17] (imports) AvoidStarImport: Using the '.*' form of import should be avoided - java.util.*.
Hello @destroydestiny Thank you for your updates. Please see my comments.
Hi @garydgregory Thank you so much for the pointers! I need to ask you how to write code rigorously. Cheers,
It's possible one of these changes is breaking the build randomly.
I need to look at this more closely over the weekend: I don't know why the HTTP providers have to be unique and different compared to all the others. Is the use of concepts in this PR backward? In the PR, the "free" code now also "closes" resources and that feels backward to me. I expect the "close" code to also "free" resources are part of closing, not the other way around. Any thoughts?
I need to look at this more closely over the weekend: I don't know why the HTTP providers have to be unique and different compared to all the others. Is the use of concepts in this PR backward? In the PR, the "free" code now also "closes" resources and that feels backward to me. I expect the "close" code to also "free" resources are part of closing, not the other way around. Any thoughts?
I think this problem needs to be considered from the beginning. The root cause is that "free" code closes httpClient. Refer to org.apache.commons.vfs2.provider.http4.Http4FileSystem#doCloseCommunicationLink