On 04/10/2016 18:12, Rory O'Donnell wrote: > Hi Mark, > > There was an update to JDK-8163449 below: > > Caching is enabled by default, but it can be disabled statically (if > strangely through a non-static api). The fact that files can't be > deleted on windows is a consequence of this caching, and also that files > are opened by the Java runtime on windows in a mode that prevents > deletion. So, really, this isn't a bug and the question is can the > submitter just disable caching? > > Let me know if that works for you ?
It doesn't. The caching causes file locking on all operating systems. It is more obvious on Windows since the OS won't let you delete the file. On Linux while you can delete the file but the space won't be freed until the lock is released. I'm aware of the ability to disable the caching and this is what Tomcat does to work-around this issue. The bug was raised because the current default triggers file descriptor leaks and lock files for JarURLConnection and that seems like a poor choice for a default. Equally, I'd rather not have to to disable all caching just to avoid a problem with one URLConnection sub-class. My hope was that rather than a single default caching option for all URLConnections, the default could be configured per protocol and that the default for the jar protocol would be changed to false. Mark > > Rgds,Rory > > On 20/09/2016 11:15, Rory O'Donnell wrote: >> >> Hi Mark, >> >> Early Access b136 <https://jdk9.java.net/download/> for JDK 9 is >> available on java.net, summary of changes are listed here >> <http://www.java.net/download/java/jdk9/changes/jdk-9+136.html>. >> Early Access b136 <https://jdk9.java.net/jigsaw/> (#5506) for JDK 9 >> with Project Jigsaw is available on java.net, summary of changes are >> listed here >> <http://www.java.net/download/java/jigsaw/archive/136/binaries/jdk-9+136.html>. >> >> There have been a number of fixes to bugs reported by Open Source >> projects since the last availability email : >> >> * 8165723 - b136 - core-libs JarFile::isMultiRelease() method >> returns false when it should return true >> * 8165116 - b136 - xml redirect function is not allowed even with >> enableExtensionFunctions >> >> NOTE:- Build 135 included a fix for JDK-8161016 which *has >> introduced a behavioral change to HttpURLConnection, more info:* >> >> The behavior of HttpURLConnection when using a ProxySelector has been >> modified with this JDK release. Currently, HttpURLConnection.connect() >> call would fallback to a DIRECT connection attempt if the configured >> proxy/proxies failed to make a connection. This release introduces a >> change whereby no DIRECT connection will be attempted in such a >> scenario. Instead, the HttpURLConnection.connect() method will fail >> and throw an IOException which occurred from the last proxy tested. >> This behavior now matches with the HTTP connections made by popular >> web browsers. But this change will bring compatibility issues for the >> applications expecting a DIRECT connection when a proxy server is down >> or when wrong proxies are provided. >> * >> >> JDK 9 Outreach Survey* >> >> In order to encourage and receive additional feedback from developers >> testing their applications with JDK 9, >> the OpenJDK Quality Outreach effort has put together a very brief >> survey about your experiences with JDK 9 so far. >> >> It is available at***https://www.surveymonkey.de/r/JDK9EA* >> >> We would love to hear feedback from you! >> >> >> Rgds,Rory >> -- >> Rgds,Rory O'Donnell >> Quality Engineering Manager >> Oracle EMEA , Dublin, Ireland > > -- > Rgds,Rory O'Donnell > Quality Engineering Manager > Oracle EMEA , Dublin, Ireland > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
