Re: Wrong Response returned for a Request
On 28 Jul 2011, at 10:16, Mark Thomas wrote: On 28/07/2011 07:34, Robert Elliot wrote: On 28 Jul 2011, at 00:24, David Rees dree...@gmail.com wrote: But perhaps this issue applies: https://issues.apache.org/bugzilla/show_bug.cgi?id=50189 -Dave Thanks very much for the pointer - however, we're using mod_proxy rather than mod_jk so presumably this wouldn't apply? mod_proxy_ajp or mod_proxy_http? If mod_proxy_ajp, then it is possible that this issue might occur (I haven't checked the source code or tested it to be sure). Mark Mod_proxy_http. We enabled the access valve with a log pattern that included the number of bytes in the response in order to be able to match requests to responses at the Tomcat level and saw that the correct responses were being returned there but incorrect ones then returned by HTTPD/mod_proxy. As we were using an old version of HTTPD we've upgraded it (from 2.2.3 to 2.2.19), and thus far we've been unable to reproduce the problem again. Thanks for the help. - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Tomcat 7 faces servlet encoding issue
Hello Everyone, when migrating my JSF 2.0 app from tomcat 6.0.32 to the version 7.0.19 I've encountered the following encoding issue. I have a simple JSF (xhtml) page with an embedded SVG image in it object type=image/svg+xml data=encoding.svg. In the web.xml file there is a faces servlet mapping set to the '/faces' path fragment. In tomcat 6 there is no difference between these two links http://drifted.in/encoding/encoding.svg http://drifted.in/encoding/faces/encoding.svg but in Tomcat 7 I am getting different results. The first is Ok while the second, processed by faces servlet, breaks the encoding. Together with my app I ship JSTL 1.1 and Mojarra 2.0.6 (jsf-api jsf-impl) libraries. Is there necessary to set something else in my app to get the same (correct) result also in Tomcat 7? I haven't found anything related here: http://wiki.apache.org/tomcat/FAQ/CharacterEncoding Any idea? Regards, Jan - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Question: Tomcat SSL configuration issue
Am Freitag, den 29.07.2011, 10:44 -1000 schrieb Sammaiah Kyatham: Hello Felix, Thanks for the response. I have received new certificated based on new CSR generated. While importing cert in to key, I'm getting the following error: java.lang.Exception: Failed to establish chain from reply Here is the keytool command that I used for this: keytool -import -alias tomcat -keystore c:/cert/final/private_key -trustcacerts -file c:/cert/final/cert.cer.txt Enter keystore password: keytool error: java.lang.Exception: Failed to establish chain from reply I think you don't want to add the cert into your trustcacert, so try removing -trustcacerts from your command line. Bye Felix I'm I missing something here Thanks in advance. Sammaiah On 27 July 2011 19:41, Felix Schumacher felix.schumac...@internetallee.dewrote: Sammaiah Kyatham sammaiahf...@googlemail.com schrieb: Hello, Your keystore has no private key. The output of keytool below shows only a certificate. You can use keytool -importkeystore to import key and certificate at the same time. Regards Felix Could you help me on this issue. I spent many hours with the various options and couldn’t resolve. I have configured the server.xml as per the tomcat configuration, however I’m getting below errors. Connector port=8443 protocol=HTTP/1.1 SSLEnabled=true keystoreFile=C:\Program Files\Java\jre6\bin\hakioskcheckin2_key keystorePass=PrivatePWD keyAlias=tomcat maxThreads=150 scheme=https secure=true clientAuth=false sslProtocol=TLS / The exception in Catelina log: Jul 27, 2011 4:28:25 PM org.apache.coyote.http11.Http11Protocol init SEVERE: Error initializing endpoint java.io.IOException: Alias name tomcat does not identify a key entry at org.apache.tomcat.util.net.jsse.JSSESocketFactory.getKeyManagers(JSSESocketFactory.java:546) at org.apache.tomcat.util.net.jsse.JSSESocketFactory.init(JSSESocketFactory.java:481) at org.apache.tomcat.util.net.jsse.JSSESocketFactory.createSocket(JSSESocketFactory.java:156) at org.apache.tomcat.util.net.JIoEndpoint.init(JIoEndpoint.java:538) at org.apache.coyote.http11.Http11Protocol.init(Http11Protocol.java:176) at org.apache.catalina.connector.Connector.initialize(Connector.java:1022) at org.apache.catalina.core.StandardService.initialize(StandardService.java:703) at org.apache.catalina.core.StandardServer.initialize(StandardServer.java:838) at org.apache.catalina.startup.Catalina.load(Catalina.java:538) at org.apache.catalina.startup.Catalina.load(Catalina.java:562) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source) at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source) When list the key using keytool, It lists alias tomcat as keytool -list -keystore hakioskcheckin2_key -storepass XX Keystore type: JKS Keystore provider: SUN Your keystore contains 1 entry tomcat, Jul 26, 2011, trustedCertEntry, Certificate fingerprint (MD5): -removed intentionally- *If I remove alias from server.xml then following exception is throwing* java.io.IOException http://download.oracle.com/javase/6/docs/api/java/io/IOException.html: jsse.invalid_ssl_conf at org.apache.tomcat.util.net.jsse.JSSESocketFactory.checkConfig(JSSESocketFactory.java:755) at org.apache.tomcat.util.net.jsse.JSSESocketFactory.init(JSSESocketFactory.java:460) at org.apache.tomcat.util.net.jsse.JSSESocketFactory.createSocket(JSSESocketFactory.java:130) at org.apache.tomcat.util.net.JIoEndpoint.init(JIoEndpoint.java:538) at org.apache.coyote.http11.Http11Protocol.init(Http11Protocol.java:176) at org.apache.catalina.connector.Connector.initialize(Connector.java:1014) at org.apache.catalina.core.StandardService.initialize(StandardService.java:680) at org.apache.catalina.core.StandardServer.initialize(StandardServer.java:795) at org.apache.catalina.startup.Catalina.load(Catalina.java:524) at org.apache.catalina.startup.Catalina.load(Catalina.java:548) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Support for a jarsToInclude property?
On 30.7.2011 0:27, Konstantin Kolinko wrote: 2. Note that you can configure JarScanner element in context.xml. Maybe it is worth to add a pair of such attributes (skip/include) there? http://tomcat.apache.org/tomcat-7.0-doc/config/jar-scanner.html That makes sense. Most of the jar files are anyway in webapps WEB-INF folder, so it is natural to keep jar scanner configuration local to the context. -Ognjen - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
tomcat log server
Hi Guys,
I have tomcat 6.0.29 running different instances on same and different
hardware, I want to create log server on one system (nfs mount the file
system), so every instance must create log files in that place like
SERVER.catalina.2011-07-30.log, SERVER1.catalina.2011-07-30.log,
SERVER.catalina.out etc. rather than ${catalina.base}/logs
Can some body guide me , really appreciated
Regards
John
Re: tomcat log server
2011/7/30 John Smith lakhil...@gmail.com:
I have tomcat 6.0.29 running different instances on same and different
hardware, I want to create log server on one system (nfs mount the file
system), so every instance must create log files in that place like
SERVER.catalina.2011-07-30.log, SERVER1.catalina.2011-07-30.log,
SERVER.catalina.out etc. rather than ${catalina.base}/logs
Can some body guide me , really appreciated
Have you tried to read documentation?
Best regards,
Konstantin Kolinko
-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Leak in Tomcat 7.0.11: a java.util.Timer seems to leave a timerThread in the JVM, and Tomcat says ...has failed to stop it. This is very likely to create a memory leak
2011/7/30 Brian Braun brianbr...@gmail.com: How do I solve it? Do I need to kill the thread somehow, or should it die as soon as I cancel the timer with the timer.cancel() method? It was discussed recently. See thread Terminating Timer Thread Gracefully starting with July 12th. Best regards, Konstantin Kolinko - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Leak in Tomcat 7.0.11: a java.util.Timer seems to leave a timerThread in the JVM, and Tomcat says ...has failed to stop it. This is very likely to create a memory leak
Hi, Where do I find that? is there an archive of the threads? Thanks! On Sat, Jul 30, 2011 at 9:14 AM, Konstantin Kolinko knst.koli...@gmail.comwrote: 2011/7/30 Brian Braun brianbr...@gmail.com: How do I solve it? Do I need to kill the thread somehow, or should it die as soon as I cancel the timer with the timer.cancel() method? It was discussed recently. See thread Terminating Timer Thread Gracefully starting with July 12th. Best regards, Konstantin Kolinko - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Leak in Tomcat 7.0.11: a java.util.Timer seems to leave a timerThread in the JVM, and Tomcat says ...has failed to stop it. This is very likely to create a memory leak
(I have just found the archive, sorry for asking something so silly) On Sat, Jul 30, 2011 at 9:21 AM, Brian Braun brianbr...@gmail.com wrote: Hi, Where do I find that? is there an archive of the threads? Thanks! On Sat, Jul 30, 2011 at 9:14 AM, Konstantin Kolinko knst.koli...@gmail.com wrote: 2011/7/30 Brian Braun brianbr...@gmail.com: How do I solve it? Do I need to kill the thread somehow, or should it die as soon as I cancel the timer with the timer.cancel() method? It was discussed recently. See thread Terminating Timer Thread Gracefully starting with July 12th. Best regards, Konstantin Kolinko - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: tomcat log server
- Original Message -
From: Konstantin Kolinko knst.koli...@gmail.com
To: Tomcat Users List users@tomcat.apache.org
Cc:
Sent: Saturday, July 30, 2011 6:29 AM
Subject: Re: tomcat log server
2011/7/30 John Smith lakhil...@gmail.com:
I have tomcat 6.0.29 running different instances on same and different
hardware, I want to create log server on one system (nfs mount the file
system), so every instance must create log files in that place like
SERVER.catalina.2011-07-30.log, SERVER1.catalina.2011-07-30.log,
SERVER.catalina.out etc. rather than ${catalina.base}/logs
Can some body guide me , really appreciated
Have you tried to read documentation?
Best regards,
Konstantin Kolinko
+1
In particular, have you read:
http://tomcat.apache.org/tomcat-6.0-doc/logging.html
. . . just my two cents without coffee.
/mde/
-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Leak in Tomcat 7.0.11: a java.util.Timer seems to leave a timerThread in the JVM, and Tomcat says ...has failed to stop it. This is very likely to create a memory leak
Hi Konstantine, I read all the thread, but I didn't find any conclusive response. Here are my doubts/comments, after everything I have read: - My timer creates a thread, with a name I assign to it. After my app stops, I see the thread in the JVM using the Yourkit profiler. It is clear that the thread is still there, but doing absolutely nothing (it does show any color trace in the profiler). As far as I have noticed, it dissappears after a while. Somehow, the JVM realizes the timer was already canceled, and that for that reason the thread can/must be killed. Am I right? - When Tomcat checks for leaks, it finds that the timer thread is there, and that it is related to the same classloader that is related to the app, and then warns that it could be a leak. Tomcat doesn't check if the timer has already been canceled and therefore going to dissapear in a while, it just checks that its thread is linked to the app by the same loader and that the thread still exists. Or am I wrong? What should I really do? 1- Should I try to kill the thread somehow? I don't even know how to get a reference to that thread. 2- Should I try to understand how Tomcat kills the thread in its code, and do it myself copying the code? 3- Should I just wait for a couple of seconds, inserting a delay in the contextDestroyed() method, so as to give time to the task object to finish doing whatever it does when cancelling? I don't think that would be reliable. 4- Should I set the parameter clearReferencesStopTimerThreads=true in the context, to tell Tomcat to kill the threads linked to the same loader? That would make Tomcat to leave a warning in the log also (I would prefer a clean log instead), but at least the manager would not tell me that a leak was found, when I press the Find leaks button. If I use that parameter, what will happen if there is another timer in the future that should not be killed, and it will kill it without me knowing about it? 5- Or should I just do nothing, and accept that even if the manager thinks there is a leak, it is just the timer thread that will dissappear eventually and that no leaking is really happening? On Sat, Jul 30, 2011 at 9:14 AM, Konstantin Kolinko knst.koli...@gmail.comwrote: 2011/7/30 Brian Braun brianbr...@gmail.com: How do I solve it? Do I need to kill the thread somehow, or should it die as soon as I cancel the timer with the timer.cancel() method? It was discussed recently. See thread Terminating Timer Thread Gracefully starting with July 12th. Best regards, Konstantin Kolinko - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Tomcat 7 faces servlet encoding issue
2011/7/30 honyk j.tosov...@email.cz: Hello Everyone, when migrating my JSF 2.0 app from tomcat 6.0.32 to the version 7.0.19 I've encountered the following encoding issue. I have a simple JSF (xhtml) page with an embedded SVG image in it object type=image/svg+xml data=encoding.svg. In the web.xml file there is a faces servlet mapping set to the '/faces' path fragment. In tomcat 6 there is no difference between these two links http://drifted.in/encoding/encoding.svg http://drifted.in/encoding/faces/encoding.svg but in Tomcat 7 I am getting different results. The first is Ok while the second, processed by faces servlet, breaks the encoding. Together with my app I ship JSTL 1.1 and Mojarra 2.0.6 (jsf-api jsf-impl) libraries. Is there necessary to set something else in my app to get the same (correct) result also in Tomcat 7? I haven't found anything related here: http://wiki.apache.org/tomcat/FAQ/CharacterEncoding Any idea? You have to examine what is actually is being sent to the browser. (The actual content of the stream and any HTTP headers that come with it). There are many ways how the things might break, but you are not saying what is break for you - what you are actually observing. Are both Tomcats on the same system? Maybe your system encoding is different? What component writes the svg file to the response stream, and how it does that? Best regards, Konstantin Kolinko - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Leak in Tomcat 7.0.11: a java.util.Timer seems to leave a timerThread in the JVM, and Tomcat says ...has failed to stop it. This is very likely to create a memory leak
2011/7/30 Brian Braun brianbr...@gmail.com: Hi Konstantine, I read all the thread, but I didn't find any conclusive response. Here are my doubts/comments, after everything I have read: For reference: http://markmail.org/thread/oph2acjbdptcvduf - My timer creates a thread, with a name I assign to it. After my app stops, I see the thread in the JVM using the Yourkit profiler. It is clear that the thread is still there, but doing absolutely nothing (it does show any color trace in the profiler). As far as I have noticed, it dissappears after a while. Somehow, the JVM realizes the timer was already canceled, and that for that reason the thread can/must be killed. Am I right? In short, Timer.cancel() only prevents future execution of the timer task. It does not interrupt the task that is currently being executed if there is any, nor waits for the scheduler thread to finish. Main concern here is that any task that is scheduled must complete before you shut down WebappClassLoader. - When Tomcat checks for leaks, it finds that the timer thread is there, and that it is related to the same classloader that is related to the app, and then warns that it could be a leak. Tomcat doesn't check if the timer has already been canceled and therefore going to dissapear in a while, it just checks that its thread is linked to the app by the same loader and that the thread still exists. Yes. That is what happens. 3- Should I just wait for a couple of seconds, inserting a delay in the contextDestroyed() method, so as to give time to the task object to finish doing whatever it does when cancelling? I don't think that would be reliable. At least you may do a Thread.yield() to let that other thread a chance to run (and finish). I wonder whether WebappClassLoader#clearReferencesStopTimerThread() can be improved to check whether the value of newTasksMayBeScheduled flag is already false. It does not solve the issue of a task that is being run at this very moment, though. Best regards, Konstantin Kolinko - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Leak in Tomcat 7.0.11: a java.util.Timer seems to leave a timerThread in the JVM, and Tomcat says ...has failed to stop it. This is very likely to create a memory leak
Hi Konstantine, I read all the thread, but I didn't find any conclusive response. Here are my doubts/comments, after everything I have read: For reference: http://markmail.org/thread/oph2acjbdptcvduf - My timer creates a thread, with a name I assign to it. After my app stops, I see the thread in the JVM using the Yourkit profiler. It is clear that the thread is still there, but doing absolutely nothing (it does show any color trace in the profiler). As far as I have noticed, it dissappears after a while. Somehow, the JVM realizes the timer was already canceled, and that for that reason the thread can/must be killed. Am I right? In short, Timer.cancel() only prevents future execution of the timer task. It does not interrupt the task that is currently being executed if there is any, nor waits for the scheduler thread to finish. Main concern here is that any task that is scheduled must complete before you shut down WebappClassLoader. Oh, I forgot to mention that before I cancel() the timer, I iterate on all the tasks and cancel them. I guess that guarantees that everything has finished. - When Tomcat checks for leaks, it finds that the timer thread is there, and that it is related to the same classloader that is related to the app, and then warns that it could be a leak. Tomcat doesn't check if the timer has already been canceled and therefore going to dissapear in a while, it just checks that its thread is linked to the app by the same loader and that the thread still exists. Yes. That is what happens. 3- Should I just wait for a couple of seconds, inserting a delay in the contextDestroyed() method, so as to give time to the task object to finish doing whatever it does when cancelling? I don't think that would be reliable. At least you may do a Thread.yield() to let that other thread a chance to run (and finish). How to I get a reference to the timerThread? I wonder whether WebappClassLoader#clearReferencesStopTimerThread() can be improved to check whether the value of newTasksMayBeScheduled flag is already false. It does not solve the issue of a task that is being run at this very moment, though. Best regards, Konstantin Kolinko - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org 2011/7/30 Brian Braun brianbr...@gmail.com:
RE: Tomcat 7 faces servlet encoding issue
In tomcat 6 there is no difference between these two links http://drifted.in/encoding/encoding.svg http://drifted.in/encoding/faces/encoding.svg but in Tomcat 7 I am getting different results. The first is Ok while the second, processed by faces servlet, breaks the encoding. You have to examine what is actually is being sent to the browser. (The actual content of the stream and any HTTP headers that come with it). Thanks for that hint. http://drifted.in/encoding/encoding.svg returns HTTP Content-type image/svg+xml (according to Firebug) but http://drifted.in/encoding/faces/encoding.svg returns image/svg+xml;charset=ISO-8859-1 In Tomcat 6 powered web I am getting just 'image/svg+xml' in both cases. There are many ways how the things might break, but you are not saying what is break for you - what you are actually observing. http://drifted.in/encoding/faces/index.xhtml - both HTML and SVG texts should match Now I see the Content-type of that HTML page is text/html;charset=UTF-8 while that SVG in it is image/svg+xml;charset=ISO-8859-1 Are both Tomcats on the same system? Maybe your system encoding is different? It has been tested on my PC initially (Win7/64bit), but the same result I am getting now on Linux Debian (hosted site). What component writes the svg file to the response stream, and how it does that? In this test case the SVG file is static, just included in WAR. So Tomcat 7 seem to be maybe too active with adding that encoding when not it is not specified. I am just thinking where to specify that encoding for standalone SVG files. In web.xml? Jan - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Tomcat 7 faces servlet encoding issue
2011/7/30 honyk j.tosov...@email.cz: In tomcat 6 there is no difference between these two links http://drifted.in/encoding/encoding.svg http://drifted.in/encoding/faces/encoding.svg but in Tomcat 7 I am getting different results. The first is Ok while the second, processed by faces servlet, breaks the encoding. You have to examine what is actually is being sent to the browser. (The actual content of the stream and any HTTP headers that come with it). Thanks for that hint. http://drifted.in/encoding/encoding.svg returns HTTP Content-type image/svg+xml (according to Firebug) but http://drifted.in/encoding/faces/encoding.svg returns image/svg+xml;charset=ISO-8859-1 In Tomcat 6 powered web I am getting just 'image/svg+xml' in both cases. There are many ways how the things might break, but you are not saying what is break for you - what you are actually observing. http://drifted.in/encoding/faces/index.xhtml - both HTML and SVG texts should match Now I see the Content-type of that HTML page is text/html;charset=UTF-8 while that SVG in it is image/svg+xml;charset=ISO-8859-1 1) What encoding is specified in ?xml header in the svg file? 2) I suspect that you are using getWriter() to write the file somewhere. That will add encoding to the content type if you are running Tomcat 7, and IIRC you wil also observe this if you are running Tomcat 6 with *.STRICT_SERVLET_COMPLIANCE system property set to true. Maybe there is a filter that does getWriter(), or you are serving the file not as a whole response, but with include() call (like jsp:include action in JSPs). Are both Tomcats on the same system? Maybe your system encoding is different? It has been tested on my PC initially (Win7/64bit), but the same result I am getting now on Linux Debian (hosted site). What component writes the svg file to the response stream, and how it does that? In this test case the SVG file is static, just included in WAR. So, is it directly served by Tomcat's DefaultServlet? So Tomcat 7 seem to be maybe too active with adding that encoding when not it is not specified. I am just thinking where to specify that encoding for standalone SVG files. In web.xml? It can be done in mime type mapping in web.xml Best regards, Konstantin Kolinko - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Leak in Tomcat 7.0.11: a java.util.Timer seems to leave a timerThread in the JVM, and Tomcat says ...has failed to stop it. This is very likely to create a memory leak
2011/7/30 Brian Braun brianbr...@gmail.com: Oh, I forgot to mention that before I cancel() the timer, I iterate on all the tasks and cancel them. I guess that guarantees that everything has finished. It does not guarantee anything for the task that is currently being run. If you look at the Javadoc for TimerTask.cancel(): (If the task is running when this call occurs, the task will run to completion, but will never run again.) Best regards, Konstantin Kolinko - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
RE: Tomcat 7 faces servlet encoding issue
Thanks for that hint. http://drifted.in/encoding/encoding.svg returns HTTP Content-type image/svg+xml (according to Firebug) but http://drifted.in/encoding/faces/encoding.svg returns image/svg+xml;charset=ISO-8859-1 In Tomcat 6 powered web I am getting just 'image/svg+xml' in both cases. 1) What encoding is specified in ?xml header in the svg file? UTF-8 2) I suspect that you are using getWriter() to write the file somewhere. That will add encoding to the content type if you are running Tomcat 7, I suspect Mojarra from that or Faces Servlet respectively. They process all the requests with that 'faces' URL fragment. and IIRC you wil also observe this if you are running Tomcat 6 with *.STRICT_SERVLET_COMPLIANCE system property set to true. You are right! So it explains the 6 vs. 7 difference ! I am just thinking where to specify that encoding for standalone SVG files. In web.xml? It can be done in mime type mapping in web.xml I've tried to change the svg mime spec to mime-mapping extensionsvg/extension mime-typeimage/svg+xml;charset=UTF-8/mime-type /mime-mapping and voila, it works! (not uploaded to the server yet) So it is not definitely a Tomcat issue. Thanks a lot for your help! Regards, Jan - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Leak in Tomcat 7.0.11: a java.util.Timer seems to leave a timerThread in the JVM, and Tomcat says ...has failed to stop it. This is very likely to create a memory leak
On 1:59 PM, Brian Braun wrote: Hi Konstantine, I read all the thread, but I didn't find any conclusive response. Here are my doubts/comments, after everything I have read: For reference: http://markmail.org/thread/oph2acjbdptcvduf - My timer creates a thread, with a name I assign to it. After my app stops, I see the thread in the JVM using the Yourkit profiler. It is clear that the thread is still there, but doing absolutely nothing (it does show any color trace in the profiler). As far as I have noticed, it dissappears after a while. Somehow, the JVM realizes the timer was already canceled, and that for that reason the thread can/must be killed. Am I right? In short, Timer.cancel() only prevents future execution of the timer task. It does not interrupt the task that is currently being executed if there is any, nor waits for the scheduler thread to finish. Main concern here is that any task that is scheduled must complete before you shut down WebappClassLoader. Oh, I forgot to mention that before I cancel() the timer, I iterate on all the tasks and cancel them. I guess that guarantees that everything has finished. - When Tomcat checks for leaks, it finds that the timer thread is there, and that it is related to the same classloader that is related to the app, and then warns that it could be a leak. Tomcat doesn't check if the timer has already been canceled and therefore going to dissapear in a while, it just checks that its thread is linked to the app by the same loader and that the thread still exists. Yes. That is what happens. 3- Should I just wait for a couple of seconds, inserting a delay in the contextDestroyed() method, so as to give time to the task object to finish doing whatever it does when cancelling? I don't think that would be reliable. At least you may do a Thread.yield() to let that other thread a chance to run (and finish). How to I get a reference to the timerThread? I wonder whether WebappClassLoader#clearReferencesStopTimerThread() can be improved to check whether the value of newTasksMayBeScheduled flag is already false. It does not solve the issue of a task that is being run at this very moment, though. Best regards, Konstantin Kolinko - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org 2011/7/30 Brian Braunbrianbr...@gmail.com: Hi, Brian- As Kris Schneider suggested, I ended up using Executors.newSingleThreadScheduledExecutor() instead of a Timer. See the last post in the thread Konstantin referenced (http://markmail.org/thread/oph2acjbdptcvduf), dated July 24, for example code. It appears to work reliably. -Terence - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Leak in Tomcat 7.0.11: a java.util.Timer seems to leave a timerThread in the JVM, and Tomcat says ...has failed to stop it. This is very likely to create a memory leak
Hi Terence, I will try that. Thanks! On Sat, Jul 30, 2011 at 3:13 PM, Terence M. Bandoian tere...@tmbsw.comwrote: On 1:59 PM, Brian Braun wrote: Hi Konstantine, I read all the thread, but I didn't find any conclusive response. Here are my doubts/comments, after everything I have read: For reference: http://markmail.org/thread/**oph2acjbdptcvdufhttp://markmail.org/thread/oph2acjbdptcvduf - My timer creates a thread, with a name I assign to it. After my app stops, I see the thread in the JVM using the Yourkit profiler. It is clear that the thread is still there, but doing absolutely nothing (it does show any color trace in the profiler). As far as I have noticed, it dissappears after a while. Somehow, the JVM realizes the timer was already canceled, and that for that reason the thread can/must be killed. Am I right? In short, Timer.cancel() only prevents future execution of the timer task. It does not interrupt the task that is currently being executed if there is any, nor waits for the scheduler thread to finish. Main concern here is that any task that is scheduled must complete before you shut down WebappClassLoader. Oh, I forgot to mention that before I cancel() the timer, I iterate on all the tasks and cancel them. I guess that guarantees that everything has finished. - When Tomcat checks for leaks, it finds that the timer thread is there, and that it is related to the same classloader that is related to the app, and then warns that it could be a leak. Tomcat doesn't check if the timer has already been canceled and therefore going to dissapear in a while, it just checks that its thread is linked to the app by the same loader and that the thread still exists. Yes. That is what happens. 3- Should I just wait for a couple of seconds, inserting a delay in the contextDestroyed() method, so as to give time to the task object to finish doing whatever it does when cancelling? I don't think that would be reliable. At least you may do a Thread.yield() to let that other thread a chance to run (and finish). How to I get a reference to the timerThread? I wonder whether WebappClassLoader#**clearReferencesStopTimerThread**() can be improved to check whether the value of newTasksMayBeScheduled flag is already false. It does not solve the issue of a task that is being run at this very moment, though. Best regards, Konstantin Kolinko --**--** - To unsubscribe, e-mail: users-unsubscribe@tomcat.**apache.orgusers-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org 2011/7/30 Brian Braunbrianbr...@gmail.com: Hi, Brian- As Kris Schneider suggested, I ended up using Executors.** newSingleThreadScheduledExecut**or() instead of a Timer. See the last post in the thread Konstantin referenced (http://markmail.org/thread/** oph2acjbdptcvduf http://markmail.org/thread/oph2acjbdptcvduf), dated July 24, for example code. It appears to work reliably. -Terence --**--**- To unsubscribe, e-mail: users-unsubscribe@tomcat.**apache.orgusers-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: [Tomcat 6.0.29] Why do I have to configure the datasource in the context.xml of the server and in the context.xml of the application?
That was only a typo. The thing is that if I remove it from any of the two places it doesn't work. I don't see anything in $CATALINA_BASE/conf/[enginename]/[hostname]/ besides the ROOT.xml but I'm using Liferay (the application is a portlet). On Mon, Jul 25, 2011 at 11:18 AM, Ognjen Blagojevic ognjen.d.blagoje...@gmail.com wrote: On 25.7.2011 16:57, AN wrote: I don't understand why do I have to place the Resource element in both files. You don't. It seems that you misconfigured something. Resource auth=Container driverClassName=oracle.jdbc.** OracleDriver Could be the source of the problem? If you deploy as WAR file, check if context.xml is indeed copied to $CATALINA_BASE/conf/[**enginename]/[hostname]/[**appname].xml, and that it contains correct resource definition. Also, check for errors in log files and console. -Ognjen --**--**- To unsubscribe, e-mail: users-unsubscribe@tomcat.**apache.orgusers-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Leak in Tomcat 7.0.11: a java.util.Timer seems to leave a timerThread in the JVM, and Tomcat says ...has failed to stop it. This is very likely to create a memory leak
Finally I have found something interesting: Tomcat has been warning me about the TimerThread, saying that it could bring leaks. And the Find Leaks button in the Tomcat Manager actually has been telling me that I do have leaks, because it notices that the class loader can't be garbage collected. But the condiction that made the class loader to be unable to unload was not actually the TimerThread, but another object that I created, that references some cryptografic libraries! I just found out that, solved it, and now its clean of leaks! I have even restarted the app a lot of times, and not only the Tomcat manager says its clean of leaks, but also the Yourkit profiler shows noe just one object of the class loader! :-) On Sat, Jul 30, 2011 at 3:28 PM, Brian Braun brianbr...@gmail.com wrote: Hi Terence, I will try that. Thanks! On Sat, Jul 30, 2011 at 3:13 PM, Terence M. Bandoian tere...@tmbsw.comwrote: On 1:59 PM, Brian Braun wrote: Hi Konstantine, I read all the thread, but I didn't find any conclusive response. Here are my doubts/comments, after everything I have read: For reference: http://markmail.org/thread/**oph2acjbdptcvdufhttp://markmail.org/thread/oph2acjbdptcvduf - My timer creates a thread, with a name I assign to it. After my app stops, I see the thread in the JVM using the Yourkit profiler. It is clear that the thread is still there, but doing absolutely nothing (it does show any color trace in the profiler). As far as I have noticed, it dissappears after a while. Somehow, the JVM realizes the timer was already canceled, and that for that reason the thread can/must be killed. Am I right? In short, Timer.cancel() only prevents future execution of the timer task. It does not interrupt the task that is currently being executed if there is any, nor waits for the scheduler thread to finish. Main concern here is that any task that is scheduled must complete before you shut down WebappClassLoader. Oh, I forgot to mention that before I cancel() the timer, I iterate on all the tasks and cancel them. I guess that guarantees that everything has finished. - When Tomcat checks for leaks, it finds that the timer thread is there, and that it is related to the same classloader that is related to the app, and then warns that it could be a leak. Tomcat doesn't check if the timer has already been canceled and therefore going to dissapear in a while, it just checks that its thread is linked to the app by the same loader and that the thread still exists. Yes. That is what happens. 3- Should I just wait for a couple of seconds, inserting a delay in the contextDestroyed() method, so as to give time to the task object to finish doing whatever it does when cancelling? I don't think that would be reliable. At least you may do a Thread.yield() to let that other thread a chance to run (and finish). How to I get a reference to the timerThread? I wonder whether WebappClassLoader#**clearReferencesStopTimerThread**() can be improved to check whether the value of newTasksMayBeScheduled flag is already false. It does not solve the issue of a task that is being run at this very moment, though. Best regards, Konstantin Kolinko --**--** - To unsubscribe, e-mail: users-unsubscribe@tomcat.**apache.orgusers-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org 2011/7/30 Brian Braunbrianbr...@gmail.com: Hi, Brian- As Kris Schneider suggested, I ended up using Executors.** newSingleThreadScheduledExecut**or() instead of a Timer. See the last post in the thread Konstantin referenced (http://markmail.org/thread/** oph2acjbdptcvduf http://markmail.org/thread/oph2acjbdptcvduf), dated July 24, for example code. It appears to work reliably. -Terence --**--**- To unsubscribe, e-mail: users-unsubscribe@tomcat.**apache.orgusers-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Tomcat 7 faces servlet encoding issue
honyk wrote: Thanks for that hint. http://drifted.in/encoding/encoding.svg returns HTTP Content-type image/svg+xml (according to Firebug) but http://drifted.in/encoding/faces/encoding.svg returns image/svg+xml;charset=ISO-8859-1 In Tomcat 6 powered web I am getting just 'image/svg+xml' in both cases. 1) What encoding is specified in ?xml header in the svg file? UTF-8 2) I suspect that you are using getWriter() to write the file somewhere. That will add encoding to the content type if you are running Tomcat 7, I suspect Mojarra from that or Faces Servlet respectively. They process all the requests with that 'faces' URL fragment. and IIRC you wil also observe this if you are running Tomcat 6 with *.STRICT_SERVLET_COMPLIANCE system property set to true. You are right! So it explains the 6 vs. 7 difference ! I am just thinking where to specify that encoding for standalone SVG files. In web.xml? It can be done in mime type mapping in web.xml I've tried to change the svg mime spec to mime-mapping extensionsvg/extension mime-typeimage/svg+xml;charset=UTF-8/mime-type /mime-mapping and voila, it works! (not uploaded to the server yet) So it is not definitely a Tomcat issue. That seems to me like a heavy-handed fix. It may work in this case, but it would break if there ever is a SVG file with an encoding different from UTF-8. Or is that not possible ? - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Tomocat 6.0.20 Comet END Event *NOT RAISED* when connection is terminated
On 29/07/2011 18:33, Sudeep Pradhan wrote: Pid, I tried Tomcat 6.0.32.. no luck yet. Even ERROR event is not raised. Can you provide a simple example which exhibits this behaviour? Also, I am seeing something weird (may not be related to this problem, but think its worth mentioning). I am seeing stale response on a new connection from curl. I validated this by changing the Accept Header from application/xml to application/json, I get 1 response in xml format and then the connection hangs. Then I do a Ctrl-C and re-try with json. I get the json response. Are the request response object not recycled properly? What can be the possible reason for this? What is stale? Take a thread dump when it hangs to see what the app is doing. p Thanks, Sudeep -Original Message- From: Pid [mailto:p...@pidster.com] Sent: Friday, July 29, 2011 12:32 AM To: Tomcat Users List Subject: Re: Tomocat 6.0.20 Comet END Event *NOT RAISED* when connection is terminated On 28/07/2011 20:42, Sudeep Pradhan wrote: Hi, I have a CometProcessor Servlet which is used for streaming system events to a http client. I have SSL enabled on the server. I use *curl* as the http client. I get streaming events on the console. But when I do a Ctrl-C on the console there no End event is raised and hence the connection is not cleaned up (I have connection registry for keeping track of clients). What can be the explanation for this scenario? Thanks, Sudeep Are you able to upgrade to 6.0.32? There have been many fixes to the NIO connector since 6.0.20 - not that this is necessarily your problem. Does the ERROR event fire when curl stops? p - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Tomcat 7.0.11: Find Leaks Button says there is a leak... then after a few minutes, it says the opposite (without any restarts in between)!
Hi, I'm using Tomcat 7.0.11. I have noticed that after a reload of an app, the Find Leaks button sometimes declares that there is a leak. But after a few minutes (without restarting/stopping/reloading the app) it says that there are no leaks. I guess the reason is that some objects are refering to the class loader and avoiding it to be garbage collected when we press the Find leaks button the first time, so it finds the leak. Then, somehow, those objects that retain the class loader dissappear or stop reffering to it, so then the class loader is collected by the GC. So then when I press the button, it says no leaks. Question: Does it mean that it is not reliable to press the button immediately after the app restart, and that I should wait for a while before doing it?
Mod_jk fails to connect via ajp13
Hi - I tried to submit a posting for a failing mod_jk but now I see that it is not possible to submit messages here because this mailing interface is even worse than mod_jk. Shame on apache, I should move to IIS. I would never have thought I'd eveer say this. - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Mod_jk fails to connect via ajp13
If you can submit this one, you can submit the mod_jk issue. Give it a try. Both works, mod_jk and this list. Kindly and best regards --Original Message-- From: Franz To: users@tomcat.apache.org ReplyTo: Tomcat Users List Subject: Mod_jk fails to connect via ajp13 Sent: Jul 30, 2011 23:16 Hi - I tried to submit a posting for a failing mod_jk but now I see that it is not possible to submit messages here because this mailing interface is even worse than mod_jk. Shame on apache, I should move to IIS. I would never have thought I'd eveer say this. - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org Enviado desde blackberry - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
