On 30/11/2016 09:49, Rory O'Donnell wrote: > Hi Mark, > > The bug has been updated with the following suggestion, any comment ?
Hi Rory, That would certainly be a good step in the right direction. It would enable the problem to be fixed for "jar:" without negatively impacting all the other protocols. What would make it perfect would be also changing the default for the "jar:" protocol to "do not cache" rather than "cache". Kind regards, Mark > > Rgds,Rory > > "We could possibly add an API to explicitly set the default > independently per protocol. So, it would then be possible to disable it > for jar: URLs, but not other URL types. This would be a new API > obviously, and therefore only available from the release in which it is > introduced. " > > > > On 05/10/2016 09:17, Rory O'Donnell wrote: >> Thanks Mark, I'll update the bug. >> >> Rgds,Rory >> >> >> On 05/10/2016 09:15, Mark Thomas wrote: >>> 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
