You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tomcat.apache.org by Mark Thomas <ma...@apache.org> on 2016/12/01 14:12:56 UTC
Re: Early Access build 136 for JDK 9 & JDK 9 with Project Jigsaw are
available on java.net
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-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
Re: Early Access build 136 for JDK 9 & JDK 9 with Project Jigsaw are
available on java.net
Posted by Rory O'Donnell <ro...@oracle.com>.
Thanks Mark,
I updated the bug with your comments.
Rgds,Rory
On 01/12/2016 14:12, Mark Thomas wrote:
> 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
>>>>>
--
Rgds,Rory O'Donnell
Quality Engineering Manager
Oracle EMEA , Dublin, Ireland
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org