[Bug 58295] New: Infinite loop in comet end event

[bugzilla]

https://bz.apache.org/bugzilla/show_bug.cgi?id=58295

Bug ID: 58295
   Summary: Infinite loop in comet end event
   Product: Tomcat 7
   Version: 7.0.64
  Hardware: PC
OS: Linux
Status: NEW
  Severity: normal
  Priority: P2
 Component: Catalina
  Assignee: dev@tomcat.apache.org
  Reporter: francesco.car...@mperience.com

-- 
You are receiving this mail because:
You are the assignee for the bug.

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

[Bug 58295] Infinite loop in comet end event

[bugzilla]

https://bz.apache.org/bugzilla/show_bug.cgi?id=58295

--- Comment #1 from Francesco Carusi  ---
Hello!

in some rare cases we are experimenting a strange behavior in our comet
implementation, we only see this once or twice a day in production (with around
20.000 unique visitors from browsers and mobile devices).
The application gets a ClientAbortException when closing an END comet event. It
seems that the END event is then dispatched again and again since it was not
successfully closed.
I attached the stack trace that the application logs on each event.close()
The tomcat server is behind a nginx reverse proxy, I don't know if this may
help.

Since we are not able to recreate the issue in our test environment we did not
investigate using a debugger.

Thanks!
Francesco

-- 
You are receiving this mail because:
You are the assignee for the bug.

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

[Bug 58295] Infinite loop in comet end event

[bugzilla]

https://bz.apache.org/bugzilla/show_bug.cgi?id=58295

--- Comment #2 from Francesco Carusi  ---
Created attachment 33046
  --> https://bz.apache.org/bugzilla/attachment.cgi?id=33046&action=edit
stack trace

-- 
You are receiving this mail because:
You are the assignee for the bug.

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

[Bug 58296] New: Possible memory leak in JspRuntimeContext

[bugzilla]

https://bz.apache.org/bugzilla/show_bug.cgi?id=58296

Bug ID: 58296
   Summary: Possible memory leak in JspRuntimeContext
   Product: Tomcat 8
   Version: 8.0.26
  Hardware: PC
Status: NEW
  Severity: normal
  Priority: P2
 Component: Jasper
  Assignee: dev@tomcat.apache.org
  Reporter: christoph.e...@mgm-tp.com

Limitation of maxLoadedJsps and usage of tag files may result in a memory leak
in JspRuntimeContext.

Steps to reproduce the leak:

1) Set Tomcat in its web.xml to production mode and limit the max jsp count to
2


maxLoadedJsps
2


development
false


2) deploy the attach WAR-file "tomcat-test.war". The WAR contains one
HttpServlet, three jsps and one tag file. GET-Requests to
http://localhost:8080/tomcat-test/test render the jsps in the sequence "1.jsp"
-> "2.jsp" -> "3.jsp". 
JSPs 1.jsp and 3.jsp use the tag "test.tag", 2.jsp contains only html.

3) make at least 5 GET-Requests to http://localhost:8080/tomcat-test/test

4) take a heap dump

5) open the dump with Eclipse MAT

6) execute the OOQL-Query 
select * from org.apache.jasper.util.FastRemovalDequeue$Entry e where
e.valid=false

7) "Path To GC Roots" (right click on one result) shows that the invalid
entries are in the retained heap of the tag's JspServletWrapper and hence in
the retained heap of JspRuntimeContext.

The retained heap of JspRuntimeContext grows with every unloaded Jsp (its Entry
in the jspQueue).

The bug is reproducible with Tomcat 7.0.52 and 8.0.26.


Supposed causes:

1) FastRemovalDequeue: removed Entry-instances are flagged as invalid. The
"previous"-field of removed elements isn't set to null. So removed elements
still reference their "previous" element (which still may be in the jspQueue of
JspRuntimeContext)

2) JspServletWrappers of currently loaded jsps and tag files are stored in the
ConcurrentHashMap "jsps" in JspRuntimeContext. JspServletWrappers of Tag files
hold (indirectly over JspCompilationContext -> JasperTagInfo ->
ImplicitTagLibraryInfo -> ParserController) references to JspServletWrapper
instances with already removed "unloadHandles" (FastRemovalDequeue$Entry
instances with valid == false). 

2) leads in combination with 1) to a reproducible memory leak: the chain of
"previous" linked entries contains all JspServletWrappers of unloaded and
currently loaded jsps. In combination with maxLoadedJsps != -1, the chain can
grow till an OutOfMemoryError occurs.

-- 
You are receiving this mail because:
You are the assignee for the bug.

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

[Bug 58296] Possible memory leak in JspRuntimeContext

[bugzilla]

https://bz.apache.org/bugzilla/show_bug.cgi?id=58296

--- Comment #1 from Christoph Empl  ---
Created attachment 33047
  --> https://bz.apache.org/bugzilla/attachment.cgi?id=33047&action=edit
war to reproduce the bug

-- 
You are receiving this mail because:
You are the assignee for the bug.

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

[Bug 58296] Possible memory leak in JspRuntimeContext

[bugzilla]

https://bz.apache.org/bugzilla/show_bug.cgi?id=58296

--- Comment #2 from Christoph Empl  ---
Created attachment 33048
  --> https://bz.apache.org/bugzilla/attachment.cgi?id=33048&action=edit
Chain with previous linked FastRemovalDequeue$Entry instances - Eclipse MAT
Screenshot

-- 
You are receiving this mail because:
You are the assignee for the bug.

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

[Bug 58296] Possible memory leak in JspRuntimeContext

[bugzilla]

https://bz.apache.org/bugzilla/show_bug.cgi?id=58296

--- Comment #3 from Christoph Empl  ---
Created attachment 33049
  --> https://bz.apache.org/bugzilla/attachment.cgi?id=33049&action=edit
JspRuntimeContext: retained heap contains invalid entry

-- 
You are receiving this mail because:
You are the assignee for the bug.

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

[Bug 58296] Possible memory leak in JspRuntimeContext

[bugzilla]

https://bz.apache.org/bugzilla/show_bug.cgi?id=58296

sherold@gmail.com changed:

   What|Removed |Added

 CC||sherold@gmail.com
 OS||All

-- 
You are receiving this mail because:
You are the assignee for the bug.

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

[Bug 58296] Possible memory leak in JspRuntimeContext

[bugzilla]

https://bz.apache.org/bugzilla/show_bug.cgi?id=58296

Robert Augustin  changed:

   What|Removed |Added

 CC||therob256+...@gmail.com

-- 
You are receiving this mail because:
You are the assignee for the bug.

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

svn commit: r1698316 - in /tomcat/jk/trunk: native/common/jk_status.c xdocs/miscellaneous/changelog.xml

[rjung]

Author: rjung
Date: Fri Aug 28 12:12:18 2015
New Revision: 1698316

URL: http://svn.apache.org/r1698316
Log:
BZ 58286: Fix crash in mod_jk and in the ISAPI
Redirector. The crash only happens on Windows
when retrieving the jk-status for the HTML format
(which is the default format). This regression
was introduced by the fix to BZ 54177.

Modified:
tomcat/jk/trunk/native/common/jk_status.c
tomcat/jk/trunk/xdocs/miscellaneous/changelog.xml

Modified: tomcat/jk/trunk/native/common/jk_status.c
URL: 
http://svn.apache.org/viewvc/tomcat/jk/trunk/native/common/jk_status.c?rev=1698316&r1=1698315&r2=1698316&view=diff
==
--- tomcat/jk/trunk/native/common/jk_status.c (original)
+++ tomcat/jk/trunk/native/common/jk_status.c Fri Aug 28 12:12:18 2015
@@ -241,9 +241,18 @@
 #define JK_STATUS_WAIT_AFTER_UPDATE"3"
 #define JK_STATUS_REFRESH_DEF  "10"
 #define JK_STATUS_ESC_CHARS("<>?\"")
+
+#ifdef WIN32
+/* See also windows_strftime_preprocess() */
+#define JK_WINDOWS_TIMEZONE_PLACEHOLDER"+"
+#define JK_STATUS_TIME_FMT_HTML"%Y-%m-%d %H:%M:%S " 
JK_WINDOWS_TIMEZONE_PLACEHOLDER
+#define JK_STATUS_TIME_FMT_TZ  JK_WINDOWS_TIMEZONE_PLACEHOLDER
+#else
 #define JK_STATUS_TIME_FMT_HTML"%Y-%m-%d %H:%M:%S %z"
-#define JK_STATUS_TIME_FMT_TEXT"%Y%m%d%H%M%S"
 #define JK_STATUS_TIME_FMT_TZ  "%z"
+#endif
+
+#define JK_STATUS_TIME_FMT_TEXT"%Y%m%d%H%M%S"
 #define JK_STATUS_TIME_BUF_SZ  (30)
 
 #define JK_STATUS_HEAD "\n" \
@@ -764,10 +773,43 @@ static char *status_strfsize(jk_uint64_t
 } while (1);
 }
 
+#ifdef WIN32
+/* Handle time formatting aspects which are not implemented by strftime
+ * on Windows.
+ * Currently only handles numeric time zone formatting
+ * which needs to be requested using JK_WINDOWS_TIMEZONE_PLACEHOLDER
+ * in the pattern.
+ */
+static const char *windows_strftime_preprocess(const char *pattern,
+   char *buf, size_t sz) {
+char *found = strstr(pattern, JK_WINDOWS_TIMEZONE_PLACEHOLDER);
+if (found != NULL && sz > strlen(pattern)) {
+TIME_ZONE_INFORMATION tz;
+
+strcpy(buf, pattern);
+found = buf + (found - pattern);
+
+if (GetTimeZoneInformation(&tz) != TIME_ZONE_ID_INVALID) {
+tz.Bias *= -1;
+snprintf(found, strlen(JK_WINDOWS_TIMEZONE_PLACEHOLDER), 
"%c%02d%02d",
+ (tz.Bias >= 0 ? '+' : '-'), tz.Bias / 60, tz.Bias % 60);
+}
+return buf;
+} else {
+return pattern;
+}
+}
+#else
+#define windows_strftime_preprocess(x, y, z) (x)
+#endif
+
 static int status_strftime(time_t clock, int mime, char *buf_time, char 
*buf_tz,
jk_logger_t *l)
 {
 size_t rc_time;
+#ifdef WIN32
+char buf[JK_STATUS_TIME_BUF_SZ];
+#endif
 #ifdef _MT_CODE_PTHREAD
 struct tm res;
 struct tm *tms = localtime_r(&clock, &res);
@@ -778,11 +820,21 @@ static int status_strftime(time_t clock,
 JK_TRACE_ENTER(l);
 
 if (mime == JK_STATUS_MIME_HTML)
-rc_time = strftime(buf_time, JK_STATUS_TIME_BUF_SZ, 
JK_STATUS_TIME_FMT_HTML, tms);
-else {
-rc_time = strftime(buf_time, JK_STATUS_TIME_BUF_SZ, 
JK_STATUS_TIME_FMT_TEXT, tms);
+rc_time = strftime(buf_time, JK_STATUS_TIME_BUF_SZ,
+   windows_strftime_preprocess(JK_STATUS_TIME_FMT_HTML,
+   buf, 
JK_STATUS_TIME_BUF_SZ),
+   tms);
+else {
+rc_time = strftime(buf_time, JK_STATUS_TIME_BUF_SZ,
+   windows_strftime_preprocess(JK_STATUS_TIME_FMT_TEXT,
+   buf, 
JK_STATUS_TIME_BUF_SZ),
+   tms);
 }
-strftime(buf_tz, JK_STATUS_TIME_BUF_SZ, JK_STATUS_TIME_FMT_TZ, tms);
+
+strftime(buf_tz, JK_STATUS_TIME_BUF_SZ,
+ windows_strftime_preprocess(JK_STATUS_TIME_FMT_TZ,
+ buf, JK_STATUS_TIME_BUF_SZ),
+ tms);
 
 JK_TRACE_EXIT(l);
 return (int)rc_time;

Modified: tomcat/jk/trunk/xdocs/miscellaneous/changelog.xml
URL: 
http://svn.apache.org/viewvc/tomcat/jk/trunk/xdocs/miscellaneous/changelog.xml?rev=1698316&r1=1698315&r2=1698316&view=diff
==
--- tomcat/jk/trunk/xdocs/miscellaneous/changelog.xml (original)
+++ tomcat/jk/trunk/xdocs/miscellaneous/changelog.xml Fri Aug 28 12:12:18 2015
@@ -45,6 +45,12 @@
   
 
   
+58286: Fix crash in mod_jk and in the ISAPI Redirector.
+The crash only happens on Windows when retrieving the jk-status
+for the HTML format (which is the default format). This regression
+was introduced by the fix to 54177. (rjung)
+  
+  
  

[Bug 58286] Crash in jk-status on Windows (when producing HTML output)

[bugzilla]

https://bz.apache.org/bugzilla/show_bug.cgi?id=58286

Rainer Jung  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |FIXED

--- Comment #3 from Rainer Jung  ---
Fixed in r1698316, will be part of 1.2.42.

I found a way to get the timezone offset even on Windows without too much
hassle. Not very nice code though.

Tested in combination with httpd 2.4 on Windows (only for my local timezone).

Not sure, whether there is still a problem on Netware.

According to
http://www.novell.com/documentation/developer/libc/libc_vol2/data/sdk1810.html,
%z should work when using libc.

According to
http://www.novell.com/documentation/developer/clib/prog_enu/data/sdk1810.html,
%z should not be available when using clib.

Not sure, which variant of Netware - libc or clib - we actually support.

Clsing, but can be reopened, if we need a fix on Netware.

-- 
You are receiving this mail because:
You are the assignee for the bug.

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

[Bug 58284] StandardSession attempts to silently write NonSerializable objects

[bugzilla]

https://bz.apache.org/bugzilla/show_bug.cgi?id=58284

--- Comment #4 from Andrew Shore  ---
Sounds good to me. Would you prefer I submit a patch for this?

-- 
You are receiving this mail because:
You are the assignee for the bug.

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

Early Access builds for JDK 8u66 b02 and JDK 9 b78 are available on java.net

[Rory O'Donnell]

Hi Mark/Mladen,

Early Access build for JDK 8u66 b02  
is available on java.net, summary of changes are listed here. 



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


With respect to ongoing JDK 9 development, I'd like to draw your 
attention to the following requests to provide

feedback on the relevant mailing lists.

*OpenJDK JarSigner API*
JDK 9 is more restricted on calling sun.* public methods but we know 
there are users calling
sun.security.tools.jarsigner.Main to sign jar files.  A new API is 
proposed 
for 
this very purpose in OpenJDK.
Feedback on this API should be provided on the security-dev 
 mailing list.


*RFC JEP: NIST SP 800-90A SecureRandom implementations : *Feedback on 
this draft 
 
JEP should be provided
on the security-dev 
 mailing list.

*
* *Public API for internal Swing classes*
According to the JEP 200: The Modular JDK 
 we expect that classes from internal 
packages (like sun.swing) will not be
accessible. If you are using the internal Swing API and it is not 
possible to replace it by public API, please provide
feedback on the swing-dev 
 mailing list.


If you haven’t already subscribed to a list then please do so first,  
otherwise your message will be discarded as spam.


Finally, videos of presentations from the JVM Language Summit have been 
published at :
http://www.oracle.com/technetwork/java/javase/community/jlssessions-2015-2633029.html 
.



Rgds, Rory

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

[Bug 56703] "Current number of backend connections" counter ever increasing when timeouts are defined

[bugzilla]

https://bz.apache.org/bugzilla/show_bug.cgi?id=56703

--- Comment #11 from reynaldo  ---
I`ve found a good online tool for PDF editing, before buying I`ve researched
PDFfiller reviews and found this:
http://dms.cioreview.com/vendor/2015/pdffiller

-- 
You are receiving this mail because:
You are the assignee for the bug.

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

[Bug 58284] StandardSession attempts to silently write NonSerializable objects

[bugzilla]

https://bz.apache.org/bugzilla/show_bug.cgi?id=58284

--- Comment #5 from Christopher Schultz  ---
Patches are always welcome!

-- 
You are receiving this mail because:
You are the assignee for the bug.

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

[Bug 58284] StandardSession attempts to silently write NonSerializable objects

[bugzilla]

https://bz.apache.org/bugzilla/show_bug.cgi?id=58284

--- Comment #6 from Andrew Shore  ---
Great, I'll get started on it. Thanks for the guidance.

-- 
You are receiving this mail because:
You are the assignee for the bug.

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

[GitHub] tomcat-maven-plugin pull request: use provided encoding for https ...

[bmeriaux]

GitHub user bmeriaux opened a pull request:

https://github.com/apache/tomcat-maven-plugin/pull/19

use provided encoding for https conector

If we specified a custom URI encoding in the pom, it was only set for the 
http connector and not for the https one.
 this patch fix it.

You can merge this pull request into a Git repository by running:

$ git pull https://github.com/bmeriaux/tomcat-maven-plugin trunk

Alternatively you can review and apply these changes as the patch at:

https://github.com/apache/tomcat-maven-plugin/pull/19.patch

To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:

This closes #19


commit 1fca8b009056c92a21a07432e6d014393e26477b
Author: Benoit Meriaux 
Date:   2015-08-28T17:24:06Z

use provided encoding for https conector




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

Re: [Bug 56703] "Current number of backend connections" counter ever increasing when timeouts are defined

[Mark Thomas]

On 28/08/2015 13:03, bugzi...@apache.org wrote:
> https://bz.apache.org/bugzilla/show_bug.cgi?id=56703
> 
> --- Comment #11 from reynaldo  ---

I've locked this idiot's account and deleted the comment from Bugzilla.

Mark

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