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,


> 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

Reply via email to