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-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
