[GitHub] tomcat issue #33: Clear up confusion about mbeans-descriptors.xml in docs; f...

2016-08-08 Thread violetagg 
Github user violetagg commented on the issue:

https://github.com/apache/tomcat/pull/33
  
Hi,

I have one comment about renaming the page.
If there are bookmarks to that page with this change we will break these 
bookmarks.

Otherwise the change is OK.

Wdyt?

Regards,
Violeta


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org

Early Access builds of JDK 8u112 b04, JDK 9 b130 are available on java.net

2016-08-08 Thread Rory O'Donnell 


Hi Mark,

There are two fixes to bugs reported by you in b130, can you confirm 
fixes  ?


Early Access b130  for JDK 9 is 
available on java.net, summary of  changes are listed here 
.


8156824 core-libs com.sun.jndi.ldap.pool.PoolCleaner should clear its 
context class loader
8157570 core-libs sun.rmi.transport.GC retains a strong reference to the 
context class loader



Early Access b129  (#5332) for JDK 9 with 
Project Jigsaw is available on java.net, summary of changes are listed 
here 



Early Access b04  for JDK 8u112 is 
available on java.net, summary of  changes are listed here 




Rgds,Rory

--
Rgds,Rory O'Donnell
Quality Engineering Manager
Oracle EMEA , Dublin, Ireland

Re: Early Access builds of JDK 8u112 b04, JDK 9 b130 are available on java.net

2016-08-08 Thread Chris Hegarty 

> On 8 Aug 2016, at 08:51, Rory O'Donnell  wrote:
> 
> Hi Mark,
> 
> There are two fixes to bugs reported by you in b130, can you confirm fixes  ?
> 
> Early Access b130  for JDK 9 is available on 
> java.net, summary of  changes are listed here 
> .
> 
> 8156824 core-libs com.sun.jndi.ldap.pool.PoolCleaner should clear its context 
> class loader
> 8157570 core-libs sun.rmi.transport.GC retains a strong reference to the 
> context class loader

With the two changes above, then several cleanups in
JreMemoryLeakPreventionListener::lifecycleEvent can be done in a JDK 9
specific Tomcat source trunk. Otherwise, if the code needs to run on older
releases, it can be be made version specific, where it is not executed on
JDK 9 or greater.

There is another of these unnecessary retention of the context class loader
issues, 8156841 [1], that I hope to address in a near future build of JDK 9.

-Chris.

[1] https://bugs.openjdk.java.net/browse/JDK-8156841
-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org

Re: Early Access builds of JDK 8u112 b03, JDK 9 b128 are available on java.net

2016-08-08 Thread Mark Thomas 
On 22/07/2016 09:43, Rory O'Donnell wrote:
> 
> Hi Mark,
> 
> Fix for JDK-8158237: JVMTI hides critical debug information for memory
> leak tracing is in b126.
> Can you confirm fix ?

Rory,

Sorry for the delay in getting back to you. It has been a busy month.

I have just downloaded Java 9, b129 and Java 9, b130 and confirmed that
it is fixed in both.

I also checked Java 8u112, b4 and confirmed (as expected) that the
problem is still present there.

Thanks again for helping to progress this fix and please do pass on my
thanks to those working on it.

Kind regards,

Mark


> 
> Early Access b03  for JDK 8u112 is
> available on java.net, summary of  changes are listed  here
> 
> 
> Early Access b128  for JDK 9 is
> available on java.net, summary of  changes are listed here
> .
> 
> Early Access b127  (#5304) for JDK 9 with
> Project Jigsaw is available on java.net, summary of  changes are listed 
> here
> 
> 
> Alan Bateman posted new jigsaw EA builds contain initial implementation
> of current proposals , more info [0]
> 
> The jigsaw/jake forest has been updated with an initial
> implementation of the proposals that Mark brought to the
> jpms-spec-experts mailing list last week. For those that don't build
> from source then the EA build/downloads [1] has also been refreshed.
> 
> 
> Rgds,Rory
> 
> [0] http://mail.openjdk.java.net/pipermail/jigsaw-dev/2016-July/008467.html
> [1] https://jdk9.java.net/jigsaw/
> 
> -- 
> 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

Re: Early Access builds of JDK 8u112 b03, JDK 9 b128 are available on java.net

2016-08-08 Thread Rory O'Donnell 

Thanks for confirming fixes Mark.

I will pass on the kudos!

Rgds,Rory



On 08/08/2016 15:08, Mark Thomas wrote:

On 22/07/2016 09:43, Rory O'Donnell wrote:

Hi Mark,

Fix for JDK-8158237: JVMTI hides critical debug information for memory
leak tracing is in b126.
Can you confirm fix ?

Rory,

Sorry for the delay in getting back to you. It has been a busy month.

I have just downloaded Java 9, b129 and Java 9, b130 and confirmed that
it is fixed in both.

I also checked Java 8u112, b4 and confirmed (as expected) that the
problem is still present there.

Thanks again for helping to progress this fix and please do pass on my
thanks to those working on it.

Kind regards,

Mark



Early Access b03  for JDK 8u112 is
available on java.net, summary of  changes are listed  here


Early Access b128  for JDK 9 is
available on java.net, summary of  changes are listed here
.

Early Access b127  (#5304) for JDK 9 with
Project Jigsaw is available on java.net, summary of  changes are listed
here


Alan Bateman posted new jigsaw EA builds contain initial implementation
of current proposals , more info [0]

 The jigsaw/jake forest has been updated with an initial
 implementation of the proposals that Mark brought to the
 jpms-spec-experts mailing list last week. For those that don't build
 from source then the EA build/downloads [1] has also been refreshed.


Rgds,Rory

[0] http://mail.openjdk.java.net/pipermail/jigsaw-dev/2016-July/008467.html
[1] https://jdk9.java.net/jigsaw/

--
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

Re: Early Access builds of JDK 8u112 b04, JDK 9 b130 are available on java.net

2016-08-08 Thread Mark Thomas 
On 08/08/2016 11:20, Chris Hegarty wrote:
> 
>> On 8 Aug 2016, at 08:51, Rory O'Donnell  wrote:
>>
>> Hi Mark,
>>
>> There are two fixes to bugs reported by you in b130, can you confirm fixes  ?
>>
>> Early Access b130  for JDK 9 is available 
>> on java.net, summary of  changes are listed here 
>> .
>>
>> 8156824 core-libs com.sun.jndi.ldap.pool.PoolCleaner should clear its 
>> context class loader
>> 8157570 core-libs sun.rmi.transport.GC retains a strong reference to the 
>> context class loader

I can confirm that both these issues are resolved in Java 9 b130.

For the benefit of those following the Tomcat dev list, the fix is not in:
- Java 9, b129 ()jigsaw)
- Java 8u112, b4

> With the two changes above, then several cleanups in
> JreMemoryLeakPreventionListener::lifecycleEvent can be done in a JDK 9
> specific Tomcat source trunk. Otherwise, if the code needs to run on older
> releases, it can be be made version specific, where it is not executed on
> JDK 9 or greater.

Tomcat 9 targets Java EE 8 which means it has to be able to run on Java
8. Therefore, given that the above issues will be fixed in the first
Java 9 release, I intend to disable the protection if Java 9 is detected.

> There is another of these unnecessary retention of the context class loader
> issues, 8156841 [1], that I hope to address in a near future build of JDK 9.

Excellent news.

The other open issue I'm aware of related to the
JreMemoryLeakPreventionListener is this one:

https://bugs.openjdk.java.net/browse/JDK-8146961

I need to review the remaining things in JreMemoryLeakPreventionListener
to see if any of them need to be raised as bugs.

Thanks to everyone who has helped progress the fixes for these issues.

Mark


-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org

svn commit: r1755511 - in /tomcat/trunk: java/org/apache/catalina/core/JreMemoryLeakPreventionListener.java webapps/docs/changelog.xml

2016-08-08 Thread markt 
Author: markt
Date: Mon Aug  8 15:19:28 2016
New Revision: 1755511

URL: http://svn.apache.org/viewvc?rev=1755511&view=rev
Log:
Add links to JRE bugs.
Disable protection when running on a JRE that is known to be fixed.

Modified:

tomcat/trunk/java/org/apache/catalina/core/JreMemoryLeakPreventionListener.java
tomcat/trunk/webapps/docs/changelog.xml

Modified: 
tomcat/trunk/java/org/apache/catalina/core/JreMemoryLeakPreventionListener.java
URL: 
http://svn.apache.org/viewvc/tomcat/trunk/java/org/apache/catalina/core/JreMemoryLeakPreventionListener.java?rev=1755511&r1=1755510&r2=1755511&view=diff
==
--- 
tomcat/trunk/java/org/apache/catalina/core/JreMemoryLeakPreventionListener.java 
(original)
+++ 
tomcat/trunk/java/org/apache/catalina/core/JreMemoryLeakPreventionListener.java 
Mon Aug  8 15:19:28 2016
@@ -36,6 +36,7 @@ import org.apache.catalina.LifecycleList
 import org.apache.juli.logging.Log;
 import org.apache.juli.logging.LogFactory;
 import org.apache.tomcat.util.ExceptionUtils;
+import org.apache.tomcat.util.compat.JreCompat;
 import org.apache.tomcat.util.compat.JreVendor;
 import org.apache.tomcat.util.res.StringManager;
 import org.w3c.dom.Document;
@@ -80,6 +81,8 @@ public class JreMemoryLeakPreventionList
  * application. This first call will start a GC Daemon thread with the
  * thread's context class loader configured to be the web application class
  * loader. Defaults to true.
+ *
+ * @see "http://bugs.java.com/bugdatabase/view_bug.do?bug_id=JDK-8157570";
  */
 private boolean gcDaemonProtection = true;
 public boolean isGcDaemonProtection() { return gcDaemonProtection; }
@@ -134,6 +137,8 @@ public class JreMemoryLeakPreventionList
  * That thread inherits the context class loader of the current thread, so
  * that there may be a web application class loader leak if the web app
  * is the first to use LdapPoolManager.
+ *
+ * @see "http://bugs.java.com/bugdatabase/view_bug.do?bug_id=JDK-8156824";
  */
 private boolean ldapPoolProtection = true;
 public boolean isLdapPoolProtection() { return ldapPoolProtection; }
@@ -195,7 +200,7 @@ public class JreMemoryLeakPreventionList
 // Trigger the creation of the AWT (AWT-Windows, AWT-XAWT,
 // etc.) thread.
 // Note this issue is fixed in Java 8 update 05 onwards.
-if (awtThreadProtection) {
+if (awtThreadProtection && !JreCompat.isJre9Available()) {
 java.awt.Toolkit.getDefaultToolkit();
 }
 
@@ -211,8 +216,9 @@ public class JreMemoryLeakPreventionList
  * Note: Long.MAX_VALUE is a special case that causes the 
thread
  *   to terminate
  *
+ * Fixed in Java 9 onwards (from early access build 130)
  */
-if (gcDaemonProtection) {
+if (gcDaemonProtection && !JreCompat.isJre9Available()) {
 try {
 Class clazz = Class.forName("sun.misc.GC");
 Method method = clazz.getDeclaredMethod(
@@ -286,6 +292,7 @@ public class JreMemoryLeakPreventionList
 // backtrace field. Note that YourKit only shows this field
 // when using the HPROF format memory snapshots.
 // https://bz.apache.org/bugzilla/show_bug.cgi?id=58486
+// https://bugs.openjdk.java.net/browse/JDK-8146961
 DocumentBuilderFactory factory = 
DocumentBuilderFactory.newInstance();
 try {
 DocumentBuilder documentBuilder = 
factory.newDocumentBuilder();
@@ -305,7 +312,10 @@ public class JreMemoryLeakPreventionList
 }
 }
 
-if (ldapPoolProtection) {
+/*
+ * Fixed in Java 9 onwards (from early access build 130)
+ */
+if (ldapPoolProtection && !JreCompat.isJre9Available()) {
 try {
 Class.forName("com.sun.jndi.ldap.LdapPoolManager");
 } catch (ClassNotFoundException e) {

Modified: tomcat/trunk/webapps/docs/changelog.xml
URL: 
http://svn.apache.org/viewvc/tomcat/trunk/webapps/docs/changelog.xml?rev=1755511&r1=1755510&r2=1755511&view=diff
==
--- tomcat/trunk/webapps/docs/changelog.xml (original)
+++ tomcat/trunk/webapps/docs/changelog.xml Mon Aug  8 15:19:28 2016
@@ -106,6 +106,12 @@
 59888: Correctly handle tabs and spaces in quoted version 
one
 cookies when using the Rfc6265CookieProcessor. (markt)
   
+  
+A number of the JRE memory leaks addressed by the
+JreMemoryLeakPreventionListener have been fixed in Java 9
+so the as

Re: Early Access builds of JDK 8u112 b04, JDK 9 b130 are available on java.net

2016-08-08 Thread Mark Thomas 
On 08/08/2016 16:09, Mark Thomas wrote:
> I need to review the remaining things in JreMemoryLeakPreventionListener
> to see if any of them need to be raised as bugs.

I've now done this and I only found one issue that I think is reasonable
to raise as a JDK issue.

JarURLConnection needs to disable caching by default to avoid file
descriptor leaks / locked files.

I've opened a bug which is currently being tracked under JI-9042682

Mark


-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org

Re: Should the RequestDispatcher decode the provided path?

2016-08-08 Thread Wang, Andy 
On Thu, 2016-07-14 at 21:11 +0200, Mark Thomas wrote:
> > The only thing it might break was if someone tried to use a URL
> > containing a % sign that wasn't encoded:
> > 
> > String target = "/foo/bar?percent=%&hash=#";
> > request.getRequestDispatcher(target).forward(request, response);
> > 
> > Right?
> 
> Right.
> 
> > 
> > I think that case is quite rare, so I'm also +1 to introducing this
> > new
> > behavior as the *default* with an option to revert back to the
> > previous
> > behavior.
> 
> I'm leaning that way too but I won't be in a position to do anything
> about it for a couple of weeks. That should be fine since that would
> be
> in time for the next monthly release cycle.

We just ran into the problem this was intended to fix, and I'm trying
to understand the impact of the fix.  

So with the fix in place and the behavior as default, any url with a
standalone % in it would break.  

With the default behavior disabled, the RequestDispatcher would not
decode the provided path, correct?

There is no scenario where both a standalone % and the
requestdispatcher decoding the provided path would both be possible?

Thanks,
Andy

Re: Should the RequestDispatcher decode the provided path?

2016-08-08 Thread Mark Thomas 
On 08/08/2016 21:25, Wang, Andy wrote:
> On Thu, 2016-07-14 at 21:11 +0200, Mark Thomas wrote:
>>> The only thing it might break was if someone tried to use a URL
>>> containing a % sign that wasn't encoded:
>>>
>>> String target = "/foo/bar?percent=%&hash=#";
>>> request.getRequestDispatcher(target).forward(request, response);
>>>
>>> Right?
>>
>> Right.
>>
>>>
>>> I think that case is quite rare, so I'm also +1 to introducing this
>>> new
>>> behavior as the *default* with an option to revert back to the
>>> previous
>>> behavior.
>>
>> I'm leaning that way too but I won't be in a position to do anything
>> about it for a couple of weeks. That should be fine since that would
>> be
>> in time for the next monthly release cycle.
> 
> We just ran into the problem this was intended to fix, and I'm trying
> to understand the impact of the fix.  
> 
> So with the fix in place and the behavior as default, any url with a
> standalone % in it would break.

Yes.

> With the default behavior disabled, the RequestDispatcher would not
> decode the provided path, correct?

Yes.

> There is no scenario where both a standalone % and the
> requestdispatcher decoding the provided path would both be possible?

Correct. Decoding the path means any % is treated as the start of a %nn
sequence. Standalone % would need to be encoded as %25

Mark


-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org