DO NOT REPLY [Bug 46397] New: Potential memory leak with TagHandlers and JspIdConsumer
https://issues.apache.org/bugzilla/show_bug.cgi?id=46397 Summary: Potential memory leak with TagHandlers and JspIdConsumer Product: Tomcat 6 Version: unspecified Platform: Macintosh OS/Version: Mac OS X 10.4 Status: NEW Severity: normal Priority: P2 Component: Jasper AssignedTo: dev@tomcat.apache.org ReportedBy: jochen.wut...@gmx.de Created an attachment (id=23022) --> (https://issues.apache.org/bugzilla/attachment.cgi?id=23022) test case app As a follow up on the thread on the mailing list, here's my summary again: Since the JSP Spec says that TagHandlers implementing JspIdConsumer may not be reused, I was expecting them to be collected after the servlet finishes processing. A few experiments showed that that is not the case. After delving into the details of the servlet code generated for JSP pages I discovered that the methods instantiating TagHandlers also store them in TagHandlerPools using #reuse(). I ran some more experiments to see what happens with these TagHandlers. My setup is Tomcat 6 + MyFaces + JSF CarDemo, and I'm using AspectJ to trace creation and garbage collection of objects implementing JspIdConsumer. My experiments indicate the following: 1. JspIdConsumer instances do NOT get garbage collected after a page has finished processing. 2. JspIdConsumer instances do NOT always get garbage collected after a session times out. 3. SOME JspIdConsumer instances DO get garbage collected when a given JSP-generated page is reloaded or accessed in a different session. To obtain these results I ran Tomcat with very little heap memory (it seems it starts fine with the 64M default), loaded the car demo in several browser sessions and ran through all the other JSP/Servlet examples that come with Tomcat to increase the memory consumption and trigger GC. Unfortunately I don't have the time and tools to do a proper stress test. To provide some sort of simpler test case, I attach a WAR to use, but you still need to put the runtime library of AspectJ (aspectjrt.jar) on the classpath when running Tomcat. The behavior I observe is that whenever I load/reload the page, the JspIdConsumer objects get allocated, and some, but never all of them get GC'd. You should see messages on the console/log like Adding JspIdConsumer::: and Removed You will see three "Adding messages" for every instance created (it's a mess to track this properly), and you should see one "Removed" message for every GC'd instance. When I run grep | wc on the output, the "distance" between the number of created and GC'd object grows over time and reloads of the test page. I had this running for a bit, trying to see if after a session timeout the remaining instances would be GC'd, but they didn't. I don't know what to make of this, but it feels like Tomcat is holding on to some of the instances for too long for no good reason. In any case, considering the specification of JspIdConsumer, which states that instances may never be reused, the caching of these instances as it is done in current JSPs is unnecessary, and since these instances don't seem to be GC'd, this seems to be a memory leak. -- Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- 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
tomcat-jdbc issue
Hi, I'm using the new tomcat-jdbc connection pool with tomcat-6.0.18 on windows server 2003 and SQL Server 2000 with the jtds driver Sometimes when the db server is under heavy load, the following exception is thrown: root cause java.lang.reflect.InvocationTargetException sun.reflect.GeneratedMethodAccessor91.invoke(Unknown Source) sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) java.lang.reflect.Method.invoke(Method.java:585) org.apache.tomcat.jdbc.pool.ProxyConnection.invoke(ProxyConnection.java:78) $Proxy1.prepareStatement(Unknown Source) This seems to be intermittent and I think it may be related to the load on the db server (which we have problems with all the time). Given that this is using reflection, I know it won't be as easy to add logging etc to determine the cause, but is there a suggested tweak to either this class or another class in the package that could aid in confirming my suspicions that this is related to db load/network timeouts etc. Apart from this issue, this pool is as good as commons-dbcp and is a great drop-in replacement Thanks, Kev - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: tomcat-jdbc issue
hi Kevin, Are you sure that is all you see in your logs. We try to not swallow any error, and there should be more information. Adding logging is not an issue, we can do that fairly easily. However, the trace you show us, is not the entire story, there is more, you can ping me on email fhanik at apache dot org, if you want me to deliver you a jar with logging enabled to track this down, best Filip Kevin Jackson wrote: Hi, I'm using the new tomcat-jdbc connection pool with tomcat-6.0.18 on windows server 2003 and SQL Server 2000 with the jtds driver Sometimes when the db server is under heavy load, the following exception is thrown: root cause java.lang.reflect.InvocationTargetException sun.reflect.GeneratedMethodAccessor91.invoke(Unknown Source) sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) java.lang.reflect.Method.invoke(Method.java:585) org.apache.tomcat.jdbc.pool.ProxyConnection.invoke(ProxyConnection.java:78) $Proxy1.prepareStatement(Unknown Source) This seems to be intermittent and I think it may be related to the load on the db server (which we have problems with all the time). Given that this is using reflection, I know it won't be as easy to add logging etc to determine the cause, but is there a suggested tweak to either this class or another class in the package that could aid in confirming my suspicions that this is related to db load/network timeouts etc. Apart from this issue, this pool is as good as commons-dbcp and is a great drop-in replacement Thanks, Kev - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: tomcat-jdbc issue
Hi Filip, > Are you sure that is all you see in your logs. We try to not swallow any > error, and there should be more information. Yes you were correct, root cause java.sql.SQLException: Invalid state, the Connection object is closed. net.sourceforge.jtds.jdbc.ConnectionJDBC2.checkOpen(ConnectionJDBC2.java:1634) net.sourceforge.jtds.jdbc.ConnectionJDBC2.prepareStatement(ConnectionJDBC2.java:2328) sun.reflect.GeneratedMethodAccessor91.invoke(Unknown Source) sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) java.lang.reflect.Method.invoke(Method.java:585) org.apache.tomcat.jdbc.pool.ProxyConnection.invoke(ProxyConnection.java:78) $Proxy1.prepareStatement(Unknown Source) com.thehut.tabernus.service.SiteService.postPopulateBean(SiteService.java:75) So it seems that the connection has been closed before the method is invoked Kev - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
DO NOT REPLY [Bug 46400] New: jspc does not work correctly if the dectination is windows unc path
https://issues.apache.org/bugzilla/show_bug.cgi?id=46400
Summary: jspc does not work correctly if the dectination is
windows unc path
Product: Tomcat 6
Version: 6.0.14
Platform: PC
OS/Version: Windows XP
Status: NEW
Severity: normal
Priority: P2
Component: Jasper
AssignedTo: dev@tomcat.apache.org
ReportedBy: hrend...@gmail.com
Run the following commands:
> cd
d:\testunc
> java -cp org.apache.jasper.JspC
-d \\server001\mytestdir\compiledjsp
-webapp \\server001\test\mywebapp
-p jsp.precompiled.webapp
-source 1.4 -target 1.4
The java classes are generated; but placed to wrong location:
d:\mytestdir\compiledjsp
The server name is ignored, the directory is created on the current drive.
Most probably, the problem is caused by the deprecated File.toURL() method,
which does not process UNC paths correctly.
For example, in the JspCompilationContext class:
protected void createOutputDir() {
...
baseUrl = options.getScratchDir().toURL();
...
}
--
Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email
--- 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
Re: tomcat5.exe on Windows x64
One other comment. It appears that this executable is explicitly setting the access flags so that registry entries are created in the HKLM\Software\Wow6432Node. I don't see any good reason for this. I notice that the ISAPI redirector does not set this flag, so it depends upon the appropriate keys being in HKLM\Software. It seems to me that things should be consistent and I think that since 64 bits is the future, the keys that procrun creates should be written to the 64 bit registry, and not the Wow6432Node. jean-frederic clere wrote: George Sexton wrote: George Sexton wrote: When I looked at the Commons-Daemon one, all of the entries were 3 or more years old, so I didn't think it was in use. At least the change log didn't have anything more current than 3 years... I will try to check the JIRA's of commons=daemon and fix what needed to be fix around Christmas. Cheers Jean-Frederic - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org -- George Sexton MH Software, Inc. Voice: +1 303 438 9585 URL: http://www.mhsoftware.com/ - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Jk Connector IIS ISAPI redirect enhancement (right list?)
Hi, I am trying to find the right mail list to submit an enhancement to the Tomcat IIS ISAPI redirect connector. I have many (several hundred) instances of tomcat using the IIS ISAPI redirect filter. I updated to version 1.2.27 of the ISAPI_redirect.dll to use the new environment variables (JKISAPI_PATH, JKISAPI_NAME) so that I don't have to edit each property file with full file paths. However, it appears the ISAPI filter gets confused sometimes and writes to log files of other instances. So, I would like to provide an enhancement to be able to have an isapi_redirect.properties file like the following: ### # Relative path to the log file for the ISAPI Redirector log_file=isapi_redirect.log # Relative path to the workers.properties file worker_file=workers.properties # Relative path to the uriworkermap.properties file worker_mount_file=uriworkermap.properties ### I have changed my local copy of jk_isapi_plugin.c to prefix the above 3 properties with the path of the ISAPI DLL if no path is present. Please point me in the right direction. TIA, Eugene -- Eugenio Alvarez MotionPoint Corporation - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
DO NOT REPLY [Bug 46403] New: Persistent cookies written by 6.0.18 do not work in Internet Explorer or Safari
https://issues.apache.org/bugzilla/show_bug.cgi?id=46403 Summary: Persistent cookies written by 6.0.18 do not work in Internet Explorer or Safari Product: Tomcat 6 Version: 6.0.18 Platform: PC URL: http://cephas.net/blog/2008/11/18/tomcat-6018-version-1- cookies-acegi-remember-me-and-ie/ OS/Version: Linux Status: NEW Severity: major Priority: P2 Component: Catalina AssignedTo: dev@tomcat.apache.org ReportedBy: m...@editme.com This blog post shows up in Google when searching for this problem, and is a better explanation that I can give here: http://cephas.net/blog/2008/11/18/tomcat-6018-version-1-cookies-acegi-remember-me-and-ie/ To summarize, in 6.0.18, the way Tomcat writes persistent cookie headers was changed from: Set-Cookie: yankeessuck=YWFyb246MTIyODI0ODEwMjk5NjoyOGM5ODc4YzExOGZiOGZjZTBkZDE0ZTA1ZWRhZTM3Nw==; Expires=Thu, 19-Nov-2009 02:29:29 GMT; to: Set-Cookie: yankeessuck="YWFyb246MTIyODI0ODEwMjk5NjoyOGM5ODc4YzExOGZiOGZjZTBkZDE0ZTA1ZWRhZTM3Nw=="; Version=1; Max-Age=31536000; The value was enclosed in quotes, a "Version=1" parameter was added, and the Expires parameter was replaced with a Max-Age parameter. Though cookies are written correctly to specification, Internet Explorer (6 and 7) and Safari do not support the Max-Age parameter. As a result, an application writing persistent cookies in this version of Tomcat won't work for Internet Explorer or Safari. -- Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- 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
DO NOT REPLY [Bug 46403] Persistent cookies written by 6.0.18 do not work in Internet Explorer or Safari
https://issues.apache.org/bugzilla/show_bug.cgi?id=46403 --- Comment #1 from Matt Wiseley 2008-12-15 17:52:34 PST --- Created an attachment (id=23027) --> (https://issues.apache.org/bugzilla/attachment.cgi?id=23027) Simple JSP that reproduces the behavior. -- Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- 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
DO NOT REPLY [Bug 46403] Persistent cookies written by 6.0.18 do not work in Internet Explorer or Safari
https://issues.apache.org/bugzilla/show_bug.cgi?id=46403 --- Comment #2 from Matt Wiseley 2008-12-15 19:26:41 PST --- Created an attachment (id=23028) --> (https://issues.apache.org/bugzilla/attachment.cgi?id=23028) Patch to always include Expires parameter regardless of version This patch adds the Expires cookie parameter in addition to the Max-Age parameter. Though not technically to the cookies spec, it works. Tested in Google Chrome, Firefox 3.0 and IE7. -- Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- 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
Re: Jk Connector IIS ISAPI redirect enhancement (right list?)
On 15.12.2008 20:23, Eugenio Alvarez wrote: Hi, I am trying to find the right mail list to submit an enhancement to the Tomcat IIS ISAPI redirect connector. I have many (several hundred) instances of tomcat using the IIS ISAPI redirect filter. I updated to version 1.2.27 of the ISAPI_redirect.dll to use the new environment variables (JKISAPI_PATH, JKISAPI_NAME) so that I don't have to edit each property file with full file paths. However, it appears the ISAPI filter gets confused sometimes and writes to log files of other instances. So, I would like to provide an enhancement to be able to have an isapi_redirect.properties file like the following: ### # Relative path to the log file for the ISAPI Redirector log_file=isapi_redirect.log # Relative path to the workers.properties file worker_file=workers.properties # Relative path to the uriworkermap.properties file worker_mount_file=uriworkermap.properties ### I have changed my local copy of jk_isapi_plugin.c to prefix the above 3 properties with the path of the ISAPI DLL if no path is present. Please point me in the right direction. A good start is bugzilla: https://issues.apache.org/bugzilla/enter_bug.cgi?product=Tomcat+Connectors You can file an enhancement request, describe the problem and solution and attach your suggested patch there. It will help us keep track of it. Regards, Rainer - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
