Re: Performance Issue while upgrading from Embedded Tomcat 6 to Tomcat 7
It might be weird but its confusing me a lot. I used HttpClient 4.2.1 for Tomcat 6.0.18 and I used the same client with Tomcat 7.0.30,causing the CPU utilization and reduced trans/sec. Now,the same thing I have tested with Apache Jmeter 2.6,and its working fine. Any possible reasons? Thanks. From: Chirag Dewan chirag.dewa...@yahoo.in To: Tomcat Users List users@tomcat.apache.org Sent: Monday, 20 May 2013 8:08 PM Subject: Re: Performance Issue while upgrading from Embedded Tomcat 6 to Tomcat 7 I ran my test client on Hello World example servlet on Tomcat 7.0.30. It was 12K req/sec with 80% CPU utilization. The same test case on tomcat 6.0.18 gave me similar req/sec but CPU utilization of 70% . The results on my linux server,with client and server running on the same machine. But all I am doing is comparing the 2 instances in the same environement. I am pretty sure the utilization is due to the server. The Jprofiler shows a lot of logging threads in tomcat consuming a lot of memory. Something I should be careful about? Also I ran an asynchronous servlet with the same client. The trans/sec reduced drastically,but the CPU utilization was only 4% Are there too may threads waiting for connection? Would thread pooling help,if we can? Thanks. From: Mark Thomas ma...@apache.org To: Tomcat Users List users@tomcat.apache.org Sent: Monday, 20 May 2013 1:48 PM Subject: Re: Performance Issue while upgrading from Embedded Tomcat 6 to Tomcat 7 On 20/05/2013 06:59, Chirag Dewan wrote: Hi, I have profiled the application using JProfiler,and it seems to me that its my servlet which is taking the majority of time. Though the time is in mili seconds,but I guess since the servlet is code is same as with Tomcat 6.0.18 is it the Servlet 3.0 API which is causing the reduced throughput? If the time is being spent in your servlet then it can't possibly be the Servlet 3.0 implementation causing the delay since that would be time spent inside Tomcat code, not your code. Mark - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
permgen space increases every day
My application running on tomcat ,every day I see an increase in permgen space, does this ever garbage collected? how can I see whats in the permgen space? I guess Heap dump shows whats in the heap memory, how about permgen space , I want to know why its increasing everyday? Tomcat 6.35 jdk 1.6 Note# I am not redeploying any application in tomcat and I just have my app and not even the manager app.I always restart the server if I have to redeploy my app. Please advice . -- View this message in context: http://tomcat.10.x6.nabble.com/permgen-space-increases-every-day-tp4999275.html Sent from the Tomcat - User mailing list archive at Nabble.com. - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
CORS on Tomcat?
Does Tomcat support setting this header on the server? Header set Access-Control-Allow-Origin * If yes, where do we set it? Leo
Re: Performance Issue while upgrading from Embedded Tomcat 6 to Tomcat 7
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Chirag, On 5/20/13 10:38 AM, Chirag Dewan wrote: I ran my test client on Hello World example servlet on Tomcat 7.0.30. It was 12K req/sec with 80% CPU utilization. The same test case on tomcat 6.0.18 gave me similar req/sec but CPU utilization of 70% . The results on my linux server,with client and server running on the same machine. But all I am doing is comparing the 2 instances in the same environement. Running both client and server on the same machine is not a great test if you want to determine the server load by looking at CPU utilization. Were you looking at overall CPU utilization, or just utilization of the Tomcat JVM process? I am pretty sure the utilization is due to the server. The Jprofiler shows a lot of logging threads in tomcat consuming a lot of memory. Something I should be careful about? Can you be more specific? AFAIK, there are no logging threads in Tomcat at all. Also I ran an asynchronous servlet with the same client. The trans/sec reduced drastically,but the CPU utilization was only 4% I would expect a small reduction in trans/sec when using async, but nothing I would describe as drastic. Can you give us some numbers? Are there too may threads waiting for connection? Would thread pooling help, if we can? I think you mean too many connections waiting for a thread instead of the other way around. Threads are already pooled. What are your Connector configuration details, and what are the parameters for your load test? If you only have 10 connections configured, launching 10,000 clients isn't exactly a fair test. - -chris -BEGIN PGP SIGNATURE- Version: GnuPG/MacGPG2 v2.0.17 (Darwin) Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBCAAGBQJRm5UNAAoJEBzwKT+lPKRYKoEQAJeWY07c4jr1prAqvdrOyR4X X9CaWrZ4DwvsKuSn2NtZgXqf5lcLhsDzgP3Ej6cNhBx7WcK6zy8zpTZ2RdVo+YOB 1fGfdpZ6rMODT3i2UI8mAQmbG54NwA4C40ShsTpYVtdXb4GfAX+81j8HqtClr5Tf NEBq2xu4LJDc0ajE4mh+Vyr3M3wUG5CEsQAKhj3Owddtus6sltbrBs8116ZzcpQt 10COnt/e08ikyUVuAYxGZPvQ+rwhlFWuvTf0NlG9/oZSDxSb19KcdZ+vMi2HTNQr McQpVxd2RtqpTgM2NJ3uTS6rQ7R4I1moP96DOgNrU6jS2u5sJVoH98weq4AU4uxa 5sXJG4N4eaVsaFE9m2Nio3zgXZDObmF2jh1df79d7TzHkcIJHjtbZ9VHf1gLVqoW v2pWVU+7di6MiDg7P1Y8y2pXwYYF13ZVx6uozyfv6hGuGXDZkMmmg0QatpKguVXl sO3idan5klic3RJJg2zduq6PUlJZyqJJulqJas1DoUHARo6pSDkZWy1hYZQC9BGT dHgmxrA4Jo5Npq1VpiNMCXl/wCT2vKdsseqsCEQN4EIvgJWuZ5l8NkZtceQTPXtE 4CEcsSd83hIDmichkhVw3PoNHKSSFGwdRRI5sEXqW1Vv88Vj7ldtD8518vJUoQLu s2xIFlQjkJKW/W46Y+on =2P5W -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Performance Issue while upgrading from Embedded Tomcat 6 to Tomcat 7
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Chirag, On 5/21/13 6:08 AM, Chirag Dewan wrote: It might be weird but its confusing me a lot. I used HttpClient 4.2.1 for Tomcat 6.0.18 and I used the same client with Tomcat 7.0.30,causing the CPU utilization and reduced trans/sec. Now,the same thing I have tested with Apache Jmeter 2.6,and its working fine. Any possible reasons? JMeter is actually a load-testing product and much more appropriate to use than a hand-rolled client using HttpClient. I would abandon your hand-rolled load-test and use JMeter instead. - -chris -BEGIN PGP SIGNATURE- Version: GnuPG/MacGPG2 v2.0.17 (Darwin) Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBCAAGBQJRm5VIAAoJEBzwKT+lPKRYrMoP/jWKRWXHKEw4Bp2XTClhqmY9 fxvuu9HshuEjP4CJvEoDSoTOXAarLu3aiLg5HvUO/bnzdJKqy3MEn6d6EKL1reb4 5LyqbBnhFAALf/VnnSnyDuT/TAvp5QPScq0FJN1osweT91F/xYilTu2MBKXC4TUL 2swtp9VwPty6oNH+wI71b6Kw/anwS+5+9zmB/Ala4OnoUDcInGu2ox2oV3zcCgeC xdveiDJ2+QVnoNeUefwi4XbJcluYKaWfxhs851mtL567Pi66l4puvDz2qAdIHQB/ ZFBPE7iJCd0utVi9gFYBvGTYAcMlYEK8Akul+6+iv6hx2eYh8o+IlbIoMFWIshPS voaMh1rFmRmA1S+q8trSRkCn8x5j0yhDAHD9tWvQqbUGe/RFXMvxxohRZAjsUdFq zn3S5HHW8qNSst/lSHSHDbWOWxETTd9VlQsC7QZnJKkxW7uag6HaIEgCoqncIAH6 +y3QhX1Wwj/lF1uTpuYQFHZwJhRYTVDDhEQvIfn5YE11wSQtsN0ZJhlazpN5FfgF PRhj+u4sx3ZvHELd8OLS9Z74fUVtPyxFFCRYbZRMVA/NGpDGYGswLH+kBVTNUfb+ WKO0PzrfnmqPAQ0TWziFMf4WuNpvcmsYwcpWenYgXLYCAsWTSE1t59byponxsX1q MU1rl/pqjx56hKp8S1IH =uDPN -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: permgen space increases every day
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Fachhoch, On 5/21/13 10:53 AM, fachhoch wrote: My application running on tomcat ,every day I see an increase in permgen space What was PermGen usage after your webapp reached a steady-state (usually a few minutes after launch)? How much does it grow every day? Have you ever run out of PermGen or are you just concerned that you /might/ run out? does this ever garbage collected? Yes. how can I see whats in the permgen space? Use a memory profiler. I guess Heap dump shows whats in the heap memory, how about permgen space , I want to know why its increasing everyday? I believe heap dump does give you PermGen info, but the mat tool might not be great for visualizing it. Tomcat 6.35 jdk 1.6 Note# I am not redeploying any application in tomcat and I just have my app and not even the manager app.I always restart the server if I have to redeploy my app. That is good information to have. Do you do anything with RMI or use a lot of proxy classes or anything like that? PermGen is mostly filled with java.lang.Class objects. The more classes you have loaded, the more PermGen you need. If you generate lots of on-the-fly Class objects and their instances don't get collected, then the java.lang.Class objects stick around forever and fill-up your PermGen. - -chris -BEGIN PGP SIGNATURE- Version: GnuPG/MacGPG2 v2.0.17 (Darwin) Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBCAAGBQJRm5ZPAAoJEBzwKT+lPKRYTawQAJc0t5BGRSAtOtFcL/gNMi70 dsxOvL0FOXbYBcM5WE3OXOyPYMiHxQVGqe5tBTwcZrkF+cQ64V+tITrJvmRlHPMT D9TjQNBgIvI5oFX4Ik8gcCxBgEW823Nn6+Qqa7ZKIrcMCNRi76hfGYfuXopJyD0I WgsjKvbB8hgZbrCsN7uF5jfpf6CD6ataXO35jYB/Na1RAZ9az4Me5Q7Ray67svvw XY0frWD6I7oUmsfyvuwNlXkdCoB6SWZDGjqn7d/3pzFhEqUi5Th5N/qeQkKNX3kk gMc5Mt5jvd358Odc3gh4kdpbgo+BuBuEg6nXhlehhhMSvYHrbY/hNNkRhybQej3v wxLK7NY90o/i2hQHo3SrXFt9HnVOG1JVBG/hT0K5saJH5DSoMULvJ/bLvCDvNwoR +lUW6p/zyY1rZKminKlF6wyj0Kn14oXMF7ueRCGIaP05H8fwvakuOfk21nTEFptN sn3jdrvvWMggZAWcjOKFVyBSxqAFAxTqikuYgE0Hjz82mj2L2GZl8cvKcqA8r34b k9GDnshZOFMuR9dfe9o4mzTMy/RAXNkLrB3ioqRE79dMy/e8PShLNgkmzPjbasoY aqNvYsXVMF1+HvuRw+XzliwCx2EdssGhk0yT4ZfvTH1PKMHPYRP89yy7SWf7HT5B CuHOTq7lKyvpur49BNm6 =YlR/ -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: permgen space increases every day
Note: If you use various things like RMI and CMS GC and don't set one or two key properties you'll always have a perm gen leak. It's a nice feature of CMS :-) On 5/21/2013 10:44 AM, Christopher Schultz wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Fachhoch, On 5/21/13 10:53 AM, fachhoch wrote: My application running on tomcat ,every day I see an increase in permgen space What was PermGen usage after your webapp reached a steady-state (usually a few minutes after launch)? How much does it grow every day? Have you ever run out of PermGen or are you just concerned that you /might/ run out? does this ever garbage collected? Yes. how can I see whats in the permgen space? Use a memory profiler. I guess Heap dump shows whats in the heap memory, how about permgen space , I want to know why its increasing everyday? I believe heap dump does give you PermGen info, but the mat tool might not be great for visualizing it. Tomcat 6.35 jdk 1.6 Note# I am not redeploying any application in tomcat and I just have my app and not even the manager app.I always restart the server if I have to redeploy my app. That is good information to have. Do you do anything with RMI or use a lot of proxy classes or anything like that? PermGen is mostly filled with java.lang.Class objects. The more classes you have loaded, the more PermGen you need. If you generate lots of on-the-fly Class objects and their instances don't get collected, then the java.lang.Class objects stick around forever and fill-up your PermGen. - -chris -BEGIN PGP SIGNATURE- Version: GnuPG/MacGPG2 v2.0.17 (Darwin) Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBCAAGBQJRm5ZPAAoJEBzwKT+lPKRYTawQAJc0t5BGRSAtOtFcL/gNMi70 dsxOvL0FOXbYBcM5WE3OXOyPYMiHxQVGqe5tBTwcZrkF+cQ64V+tITrJvmRlHPMT D9TjQNBgIvI5oFX4Ik8gcCxBgEW823Nn6+Qqa7ZKIrcMCNRi76hfGYfuXopJyD0I WgsjKvbB8hgZbrCsN7uF5jfpf6CD6ataXO35jYB/Na1RAZ9az4Me5Q7Ray67svvw XY0frWD6I7oUmsfyvuwNlXkdCoB6SWZDGjqn7d/3pzFhEqUi5Th5N/qeQkKNX3kk gMc5Mt5jvd358Odc3gh4kdpbgo+BuBuEg6nXhlehhhMSvYHrbY/hNNkRhybQej3v wxLK7NY90o/i2hQHo3SrXFt9HnVOG1JVBG/hT0K5saJH5DSoMULvJ/bLvCDvNwoR +lUW6p/zyY1rZKminKlF6wyj0Kn14oXMF7ueRCGIaP05H8fwvakuOfk21nTEFptN sn3jdrvvWMggZAWcjOKFVyBSxqAFAxTqikuYgE0Hjz82mj2L2GZl8cvKcqA8r34b k9GDnshZOFMuR9dfe9o4mzTMy/RAXNkLrB3ioqRE79dMy/e8PShLNgkmzPjbasoY aqNvYsXVMF1+HvuRw+XzliwCx2EdssGhk0yT4ZfvTH1PKMHPYRP89yy7SWf7HT5B CuHOTq7lKyvpur49BNm6 =YlR/ -END PGP SIGNATURE- - 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: CORS on Tomcat?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Leo, On 5/21/13 11:34 AM, Leo Donahue - RDSA IT wrote: Does Tomcat support setting this header on the server? Header set Access-Control-Allow-Origin * If yes, where do we set it? You should know how to do this by now: url-rewrite. If you are using this with the CSRF prevention filter, you probably want to also mention those other domains in the entryPoints attribute. - -chris -BEGIN PGP SIGNATURE- Version: GnuPG/MacGPG2 v2.0.17 (Darwin) Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBCAAGBQJRm5ptAAoJEBzwKT+lPKRYeFsQAKbKt+E7+QqgyojS1+clM5YL SraSTcCzv/Dw9n2A7p4jqv4t+pXU149+L/KKLAdOKMCXZtX7o+Ag8yAlsly/QJ4Y mX9QDn1gfTPF6+vd26qUvnaF3WCs+ras5OCKhtpvrd99/DoKcoKwxGIYbmYp/Nyp 2a+x8tdU9T8z8YesiXUC+9Aa+pRjKnG7iBFgJmcPEMQZffXHmjfbGK4IWJ4WJYx/ wGjaS/tDlcrhrPy0QmG5e9y3PokrNdyS4nVYDjSBSGuqYby0Uvqo1OL4WvYmGXU0 gScHa6q7nuQR/kim4q2BpjqO09uqmqYl1tddNF1dRgMktEcO0jW5jJUFns/FaEDK qkKz95++U1fSwmaCNPdTRV7+Fz/jgZMN70BQoJHc258/ScMz1Hi9qoMDBYmzuyp6 esVQiwMZ/ogMKqjfHtxll9XPcilxC1B1tKYxxVef1K1Gebum10mD7HZ/zbq6HcRd EKXth9LzYCGsUXwNeplhlpDEirtO6nk3/EZMdTZFavLGxhZtGAZFNaNnzGNh/por 2mbOXR+VVmAML1W7qEljLVn8qmKGwkw9c8lwuY322r/oHaq4d1JmqOd/df2UqvfY Qhv2DO/xl9XimOT0uCEmhC0Qa1Oazm4pXfW5d5co+eXlhj0VSKAAn2RAPDxhvEVD lIIa6/f/HxuQoBEzQJTP =+rfT -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: redirect valve in tomcat
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
Anil,
On 5/20/13 10:32 AM, Anil Goyal -X (anigoyal - Aricent Technologies at
Cisco) wrote:
Hi All,
I am adding a new service in tomcat with name catalina_new and
deploy an abc application under this. This application was in
running under catalina service previously. This new service is
using connector port 8181 for http and 8444 for https. Now I want
all my request coming for this application on port 8080 to redirect
on port 8181 for http ,8443 to redirect on port 8444. My tomcat
server.xml is using a valve class Valve
className=com.cisco.unity.tomcat.valve.ConnectionRedirectValve
redirectHost=/ Some redirection logic is already written in this
valve class for some other application but that is only redirecting
the url with same port. if
(request.getContextPath().equals(/ciscopca)
request.getRequestURI().startsWith(/ciscopca/unityinbox/)) {
response.setStatus(HttpServletResponse.SC_MOVED_TEMPORARILY);
response.sendRedirect(/inbox); }
How I can make a check here for request to redirect based on port
number.
I think you are looking for HttpServletRequest.getServetPort().
You might find that url-rewrite is a better tool for you, as it's
already been written and supports a huge number of options.
http://tuckey.org/urlrewrite/
- -chris
-BEGIN PGP SIGNATURE-
Version: GnuPG/MacGPG2 v2.0.17 (Darwin)
Comment: GPGTools - http://gpgtools.org
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
iQIcBAEBCAAGBQJRm5ryAAoJEBzwKT+lPKRYXZwP/1XaADVRql3N15kVI4Pg8VoF
R1KW930iz8D9Ul6YwqNOMN5XaF6mWSMJU7dgGzQ2T1wRyh5SAeYx1OUHxRp/5djO
DT1mWhfIq8qivhvyRfn3Nf6FtpqfIGTf2P9PEUmle5lbUUwjODtx0XXNC4JgAhJo
hvddNkFM/I+XzDNJbfEhPo5rCG1sT8tRv/kgOCgZ+OqX/QZP6m2SCBQBp6qeoj3c
RK0HPZINUpl+dsnVE9BX8XAjMIRWUQoOTMB73Aq34OsmObryhaiDXl2/72YUpbhY
Ds1xG58i/Y+tG4U6fNxVfIL7D88mYvOh/79fDuNwywZHWU3TIUj8FUJwdXlW49HC
h7PYK6dWVVcYv61CvoX4g/+D2s4DxqO7BflBjsM42erflCVmZagFvDS38237iReR
niTGUoPxnUZPGuvndJC7TvvstPfngaTQOygHcOyldQ7o3v3Wkzd4k+1Ao06W1ymH
xQYT4k/AZkZjNqftPKiPhV7EwbePbpELyAhOrS1PWBN5lxCuzz1s06/6KE5qsBF3
fZFg86BTl/Dy9wGjlG6suL1Jb8S7ZvjzRpjTl+GSbb7HeX1ArDqrfkHX3lPVArKX
5FMi7qHosheaVBphV26W0ZkDczrJATGCm+FIyFqjTmPwhLvwp03YgTj5QZ/7fExT
AH9kf5ceyKd6UEpEb+Mh
=U20e
-END PGP SIGNATURE-
-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
RE: CORS on Tomcat?
-Original Message- From: Christopher Schultz [mailto:ch...@christopherschultz.net] Subject: Re: CORS on Tomcat? -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Leo, On 5/21/13 11:34 AM, Leo Donahue - RDSA IT wrote: Does Tomcat support setting this header on the server? Header set Access-Control-Allow-Origin * If yes, where do we set it? You should know how to do this by now: url-rewrite. Thanks Chris. But.. but.. Apache has it... I wanted to avoid using a proxy that turns lengthy GET requests into POST requests for one of our REST based web apps. I was reading online where Cross Origin Resource Sharing was possible on some servers. Specifically here: http://enable-cors.org/server.html If you are using this with the CSRF prevention filter, you probably want to also mention those other domains in the entryPoints attribute. - -chris
Re: permgen space increases every day
Thanks for your replies, I use spring , hibernate , wicket. For some of my objects I create proxy using spring, hibernate creates proxies and injection into wicket objects uses spring proxy. I also use groovy with spring and most of my groovy beans are of scope prototype. lang:groovy id=someId script-source=classpath:com/../..LeadAnlystReturnedAssignmentEmail.groovy scope=prototype / Whats the best way I can force tomcat to garbage collect my permgen, I am running tomcat with -Xmx1024m -Xmx1024m -XX:MaxPermSize=1024m -- View this message in context: http://tomcat.10.x6.nabble.com/permgen-space-increases-every-day-tp4999275p4999284.html Sent from the Tomcat - User mailing list archive at Nabble.com. - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
RE: CORS on Tomcat?
-Original Message- From: Leo Donahue - RDSA IT [mailto:leodona...@mail.maricopa.gov] Subject: RE: CORS on Tomcat? -Original Message- From: Christopher Schultz [mailto:ch...@christopherschultz.net] Subject: Re: CORS on Tomcat? -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Leo, On 5/21/13 11:34 AM, Leo Donahue - RDSA IT wrote: Does Tomcat support setting this header on the server? Header set Access-Control-Allow-Origin * If yes, where do we set it? You should know how to do this by now: url-rewrite. Thanks Chris. But.. but.. Apache has it... I wanted to avoid using a proxy that turns lengthy GET requests into POST requests for one of our REST based web apps. I was reading online where Cross Origin Resource Sharing was possible on some servers. Specifically here: http://enable-cors.org/server.html I realize I can set the header in the response, but was hoping this can be something we set on the server for a specific context maybe? response.setHeader(Access-Control-Allow-Origin, *); response.setHeader(Access-Control-Request-Method, GET,POST); Before IE supported this, Firefox did, which made it nice for some users who wanted to make an cross origin ajax requests to one of our servlets.
RE: CORS on Tomcat?
-Original Message- From: Leo Donahue - RDSA IT [mailto:leodona...@mail.maricopa.gov] Sent: Tuesday, May 21, 2013 9:33 AM To: Tomcat Users List Subject: RE: CORS on Tomcat? B KKK KCB [ X ܚX KK[XZ[ \ \ ][ X ܚX P X ] \X K ܙ B ܈Y][ۘ[ [X[ K[XZ[ \ \ Z[ X ] \X K ܙ B Um. I didn't say that.
Re: CORS on Tomcat?
On 21.05.2013 18:20, Leo Donahue - RDSA IT wrote: -Original Message- From: Christopher Schultz [mailto:ch...@christopherschultz.net] Subject: Re: CORS on Tomcat? -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Leo, On 5/21/13 11:34 AM, Leo Donahue - RDSA IT wrote: Does Tomcat support setting this header on the server? Header set Access-Control-Allow-Origin * If yes, where do we set it? You should know how to do this by now: url-rewrite. Thanks Chris. But.. but.. Apache has it... I wanted to avoid using a proxy that turns lengthy GET requests into POST requests for one of our REST based web apps. I was reading online where Cross Origin Resource Sharing was possible on some servers. Specifically here: http://enable-cors.org/server.html I guess Chris meant the Tuckey urlrewrite filter (http://tuckey.org/urlrewrite/) which can be used in Tomcat. Look for response-header in http://urlrewritefilter.googlecode.com/svn/trunk/src/doc/manual/4.0/guide.html. Regards, Rainer - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
RE: Apache Tomcat service has been shutting down/stopping randomly.
Below is the most recent Exception Access Violation tcnative Error we are receiving. This error log is generated every time the service randomly stops causing us to believe this to be the primary catalyst. # # A fatal error has been detected by the Java Runtime Environment: # # EXCEPTION_ACCESS_VIOLATION (0xc005) at pc=0x0001800057b2, pid=4648, tid=5464 # # JRE version: 6.0_21-b07 # Java VM: Java HotSpot(TM) 64-Bit Server VM (17.0-b17 mixed mode windows-amd64 ) # Problematic frame: # C [tcnative-1.dll+0x57b2] # # If you would like to submit a bug report, please visit: # http://java.sun.com/webapps/bugreport/crash.jsp # The crash happened outside the Java Virtual Machine in native code. # See problematic frame for where to report the bug. # --- T H R E A D --- Current thread (0x04f32800): JavaThread Finalizer daemon [_thread_in_native, id=5464, stack(0x05b5,0x05c5)] siginfo: ExceptionCode=0xc005, reading address 0x0040 Registers: EAX=0x, EBX=0x, ECX=0x0742bb60, EDX=0x07d23000 ESP=0x05c4ee30, EBP=0x, ESI=0x07457c20, EDI=0x006f EIP=0x0001800057b2, EFLAGS=0x00010206 Top of Stack: (sp=0x05c4ee30) 0x05c4ee30: 006f 0x05c4ee40: 0087 0x05c4ee50: 013959ce 013a1260 0x05c4ee60: 05c4eee0 006f 0x05c4ee70: 80c39190 0054 0x05c4ee80: 006f 006f 0x05c4ee90: dc87efd0 05c4ee98 0x05c4eea0: 05c4eea0 0x05c4eeb0: 05c4ef18 80c3a7a8 0x05c4eec0: 80c39190 0x05c4eed0: 05c4ef00 0x05c4eee0: 05c4ef60 013959ce 0x05c4eef0: 80c3a6f0 0139e316 0x05c4ef00: 006f 0x05c4ef10: 07457c20 dc87efd0 0x05c4ef20: 05c4ef20 80fbd18e Instructions: (pc=0x0001800057b2) 0x0001800057a2: 8d 44 24 38 48 89 44 24 38 48 8b 46 30 48 03 d3 0x0001800057b2: ff 50 40 85 c0 75 29 48 8b 44 24 38 48 85 c0 74 Stack: [0x05b5,0x05c5], sp=0x05c4ee30, free space=3fbk Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code) C [tcnative-1.dll+0x57b2] [error occurred during error reporting (printing native stack), id 0xc005] Java frames: (J=compiled Java code, j=interpreted, Vv=VM code) j org.apache.tomcat.jni.Socket.sendbb(JII)I+0 j org.apache.coyote.http11.InternalAprOutputBuffer.flushBuffer()V+22 j org.apache.coyote.http11.InternalAprOutputBuffer.flush()V+5 j org.apache.coyote.http11.AbstractHttp11Processor.action(Lorg/apache/coyote/ActionCode;Ljava/lang/Object;)V+130 j org.apache.coyote.Response.action(Lorg/apache/coyote/ActionCode;Ljava/lang/Object;)V+31 j org.apache.catalina.connector.OutputBuffer.doFlush(Z)V+97 j org.apache.catalina.connector.OutputBuffer.flush()V+2 j org.apache.catalina.connector.CoyoteOutputStream.flush()V+4 j javax.imageio.stream.FileCacheImageOutputStream.close()V+60 j javax.imageio.stream.ImageInputStreamImpl.finalize()V+8 v ~StubRoutines::call_stub j java.lang.ref.Finalizer.invokeFinalizeMethod(Ljava/lang/Object;)V+0 j java.lang.ref.Finalizer.runFinalizer()V+45 j java.lang.ref.Finalizer.access$100(Ljava/lang/ref/Finalizer;)V+1 j java.lang.ref.Finalizer$FinalizerThread.run()V+11 v ~StubRoutines::call_stub --- P R O C E S S --- Java Threads: ( = current thread ) 0x07148000 JavaThread http-apr-80-exec-6 daemon [_thread_blocked, id=5004, stack(0x0db5,0x0dc5)] 0x07147000 JavaThread http-apr-80-exec-5 daemon [_thread_blocked, id=636, stack(0x0da5,0x0db5)] 0x07146800 JavaThread http-apr-80-exec-4 daemon [_thread_blocked, id=1696, stack(0x0d95,0x0da5)] 0x07146000 JavaThread http-apr-80-exec-3 daemon [_thread_blocked, id=3280, stack(0x0d85,0x0d95)] 0x07145000 JavaThread http-apr-80-exec-2 daemon [_thread_blocked, id=3300, stack(0x0d75,0x0d85)] 0x07143000 JavaThread http-apr-80-exec-1 daemon [_thread_blocked, id=1136, stack(0x0d55,0x0d65)] 0x07143800 JavaThread AWT-Windows daemon [_thread_in_native, id=5604, stack(0x0d65,0x0d75)] 0x07142000 JavaThread Java2D Disposer daemon [_thread_blocked, id=5624, stack(0x0d45,0x0d55)] 0x07141800 JavaThread http-apr-443-exec-25 daemon [_thread_blocked, id=5404,
Where is a good SSL/TLS
I've been trying to figure out how to compile Apache 2.2 on Red Hat Enterprise Linux Server release 6.4 (Santiago). I can generate both the No recognized SSL/TLS toolkit detected and Error, SSL/TLS libraries were missing or unusable errors. I assume that means I have found the correct --with-ssl path based on various openSSL configurations. I know I need a good mod_ssl and mod_jk. If there is an alternate way to get the modules I'm missing, that would be cool too. --- Thanks, Burton L. Smith w:801-584-6164 c:801-201-2897
RE: Where is a good SSL/TLS
From: Smith, Burton [mailto:burton.sm...@williams.com] Subject: Where is a good SSL/TLS I've been trying to figure out how to compile Apache 2.2 So wouldn't it be more effective to ask on the httpd mailing list rather than the Tomcat one? - Chuck THIS COMMUNICATION MAY CONTAIN CONFIDENTIAL AND/OR OTHERWISE PROPRIETARY MATERIAL and is thus for use only by the intended recipient. If you received this in error, please contact the sender and delete the e-mail and its attachments from all computers. - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Follow-up: Possible false-postive with JreMemoryLeakPreventionListener and Tomcat's JDBC Pool and OracleTimeoutPollingThread
Am 2013-05-17 14:26, schrieb Mark Thomas: On 17/05/2013 12:31, Michael-O wrote: Hi Mark, thanks again for the detailed answer, details inline. Gesendet: Freitag, 17. Mai 2013 um 11:36 Uhr Von: Mark Thomas ma...@apache.org An: Tomcat Users List users@tomcat.apache.org Betreff: Re: Follow-up: Possible false-postive with JreMemoryLeakPreventionListener and Tomcat's JDBC Pool and OracleTimeoutPollingThread On 17/05/2013 09:28, Michael-O wrote: Hi folks, there's now a follow-up on the issue [1]. Recap: JreMemoryLeakPreventionListener reported that my webapp has spawned OracleTimeoutPollingThread because I have set a QueryTimeout in the JDBC Pool. Mark Thomas noted that this is likely a bug in the driver. I have taken action and created a service request with Oracle. My personal analysis with VisualVM: The thread is spawned when the first query is run. The thread keeps running when the webapp is shut down or undeployed. Classes remain in memory. The JDBC Pool does a simple Class.forName to load the driver, it neither uses the DriverManager loading nor does it actively unload the driver. Oracle answer: They were able to reproduce the issue. The technical analysis says: Hi Michael, I confirmned internally that this message from Tomcat can be ignored as there is no risk of any real leak from OracleTimeoutPollingThread thread. This thread is related to the JDBC driver which may be used by many apps simultaneously. Unloading the app does not unload the driver and should not and does not stop the thread. It seems to be the design behaviour. So my questions would be: 1. Is that still not a false positive? No, that is not a false positive. The response from Oracle is wrong. There is nothing wrong with the driver creating the thread or the thread continuing after the web application has stopped. The problem is as follows: 1. When the JDBC driver creates the Thread, the Thread's context class loader (as returned by Thread.getContextClassLoader()) is set to the web application's class loader. 2. The correct behaviour at this point would be for the Driver to set the Thread's context class loader to the class loader that loaded the Driver class when the Thread is created. 3. The memory leak occurs as follows: - the web application is stopped - Tomcat clears all references to the web application and its classes - The web application should be eligible for garbage collection - The JDBC driver is still loaded (as it should be) - The JDBC driver retains a reference to the Thread (as it should) - The thread retains a reference to the web application class loader (this is the memory leak). The reference chain is: a) JDBC driver b) Thread c) Web application class loader d) Every class loaded by the web app Everything from c) onwards should be eligible for garbage collection but isn't because of the leak in the Thread that is retaining a reference to the web application class loader. This is what I would assume as correct behavior. If the thread is still attached ot the WebAppClassLoader, does that mean that the WebAppClassLoader cannot be garbage collected? The correct behaviour is that there is no reference to c) held by b) and therefore c) onwards would be eligible for GC (assuming the web app has been stopped). The problem here is that because b) has a reference to c), c) can't be GC'd and that is a memory leak. 2. Why does the JDBC Pool not unload the driver? That my cause the thread to stop after the last app has been stopped/undeployed. 1. Because the driver is in CATALINA_HOME/lib it is available to other applications. So first app, loads driver and keeps it in memory. Even if all apps are undeployed, driver remains cached and GCed when Tomcat is shut down? The JDBC driver will be loaded though the services API as soon as any code references the DriverManager. 2. JDBC drivers are never automatically unloaded. You have to do so explicitly (not doing so is an other source of memory leaks when the driver is packaged in WEB-INF/lib). OK, this won't be the case. Driver is always shared here. You need to go back to Oracle. Yes, I will. We're paying probably a lot of money for he company-wide license. I'd expect so. From my own experience with Oracle commercial support for things Java related, you'll have to go through the This is a bug. No it isn't. Yes it is... cycle several times before you manage to get the issue in front of someone with the necessary knowledge and skills to correctly identify this is a bug in Oracle's JDBC driver. I'd recommend escalating it through your account manager sooner rather than later. Feel free to point Oracle support to this thread and/or my presentation on memory leaks. If Oracle support require further help understanding this issue they are, of course, free to join this mailing list. Mark, I did receive an answer to the issue, citing your findings. See verbatim copy below: Hi Michael, I received the following
Re: CORS on Tomcat?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Rainer, On 5/21/13 1:07 PM, Rainer Jung wrote: On 21.05.2013 18:20, Leo Donahue - RDSA IT wrote: -Original Message- From: Christopher Schultz [mailto:ch...@christopherschultz.net] Subject: Re: CORS on Tomcat? -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Leo, On 5/21/13 11:34 AM, Leo Donahue - RDSA IT wrote: Does Tomcat support setting this header on the server? Header set Access-Control-Allow-Origin * If yes, where do we set it? You should know how to do this by now: url-rewrite. Thanks Chris. But.. but.. Apache has it... I wanted to avoid using a proxy that turns lengthy GET requests into POST requests for one of our REST based web apps. I was reading online where Cross Origin Resource Sharing was possible on some servers. Specifically here: http://enable-cors.org/server.html I guess Chris meant the Tuckey urlrewrite filter (http://tuckey.org/urlrewrite/) which can be used in Tomcat. Hah! Yes, I guess copy/paste doesn't work-out well when you don't bother to actually read what was in the paste buffer. - -chris -BEGIN PGP SIGNATURE- Version: GnuPG/MacGPG2 v2.0.17 (Darwin) Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBCAAGBQJRm77BAAoJEBzwKT+lPKRYkmkP+wQNMmoUhpxEBo+V49IVDxVJ C11Nqny6A2q2L90DxJUekC5QFAHL0Qdo37u62qV7iF4Ao7cvfnnMhTruTbm8Gdz5 +WeJI+TcBTAx1pVg/RxZBwGUy4vIrV/ivJUufl1/77LV8lyP8BQloZOG6K5zvrd8 fLEK315sPwysMfAtqfo2HMjogFzkMiiNQYHfAZJ+tXFRepMgXm4vaV3NTaMljmHB P7Fuy/TtPaoS4MzOgzoFVeVATJFC4UVRQg9IKAjX2EcK5oK18BsyGxz8XRI8Ikby 4XAWvEqS898B7tshBWNRSyBjynf0x8BQtjoTFwMNv0gvPNm1l9xd/WDo/LvwAPx/ mH4ybnvL3phWJJkybmynRA8x4b0+x81/EMtU1H1LYXcednfN5awncOvJLXQXQGYH M99MP7aappHjzJQkqb/EHNSdIs3I5EAs/R0u1LYylgYsUcqTeduJWsYb87m3uaNS wx1x1vIuvpExTdXsIXLL5FRWvzwM7aEzSl7Sc47Kya3qty9s+ayU8FYSXN9hvm0A vCtlKwPDV24J1KXIv5uL0/VGNfmhKZ7guzx6hcgxIQrY7LAENBbNdWjVzpc3l5iY xmBxLuc6IQB+ExN/pW3h1NY2rcOnyTzs3N7flmh3WeMeiETaTGgoUDmNgMXfK2ph gewuihyd6I5uIIXsb/7M =cyQ7 -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Follow-up: Possible false-postive with JreMemoryLeakPreventionListener and Tomcat's JDBC Pool and OracleTimeoutPollingThread
On 21/05/2013 19:01, Michael-O wrote: Mark, I did receive an answer to the issue, citing your findings. See verbatim copy below: Hi Michael, I received the following update from our developer: ** The theoretical problem is that the thread is holding the app class loader so it remains reachable and the app is never unloaded. So if the user loads and unloads the app, the app classes remain in memory. Subsequent loading and unloading of the app will not get pinned in memory as the thread is already running so the subsequent loading and unloading will not cause additional class loaders to be pinned. It is a fixed size memory leak. It does not grow. The thread suggests setting the context class loader to be the parent of the default context class loader. This may work in Tomcat but it's pretty random. I am researching the problem to determine what if anything the driver should do to work across all containers. A Tomcat specific fix is not acceptable. Almost but not quite. The correct fix is to set the context class loader of the Thread to the class loader that loaded the Driver or, alternatively, the class loader that loaded the thread class. As Mark Thomas pointed out it is critical that the driver is loaded in the boot or system or container class loader, not the app class loader. If the driver is in the app class loader then when the app is unloaded the driver also should be unloaded. Unfortunately this doesn't work. The driver itself remains reachable so the app class loader is reachable so the app is never unloaded. At present there is no general way to solve this problem. The necessary hooks are added in JDK 8. I'd agree to this point. Most users put the driver in the container, not the app, so this is rarely a problem. I don't agree with this. I often see this with JDBC drivers which is why Tomcat has a pile of code specifically to unpick the mess this creates. ** I will certainly have to fill out a bug to have it investigated officially. That is good news. Seems like they understood the problem. But I do doubt that this is a fixed size moemory leak. I think the point they are trying to make is that it is only the first instance of the web application to be unloaded that will be pinned in memory. Subsequent reloads won't trigger a leak. That is correct. Mark - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Follow-up: Possible false-postive with JreMemoryLeakPreventionListener and Tomcat's JDBC Pool and OracleTimeoutPollingThread
Am 2013-05-21 20:38, schrieb Mark Thomas: Seems like they understood the problem. But I do doubt that this is a fixed size moemory leak. I think the point they are trying to make is that it is only the first instance of the web application to be unloaded that will be pinned in memory. Subsequent reloads won't trigger a leak. That is correct. Does this mean that only one WebAppClassLoader stays in memory because the thread is launched once and attached to that class loader? Michael - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Apache Tomcat service has been shutting down/stopping randomly.
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 James, On 5/21/13 1:25 PM, James Snider wrote: Below is the most recent Exception Access Violation tcnative Error we are receiving. This error log is generated every time the service randomly stops causing us to believe this to be the primary catalyst. So now the big question: can you reliably trigger the primary catalyst? If so, we can try a few things. First, figure out how to blow-up your application. That shouldn't be that tough: just make sure you exercise the code that uses ImageIO to write directly to a ServletOutputStream. Since you said that you aren't using ImageIO, this might present a challenge but you are going to have to find it. Next, implement the OutputStream-wrapper[1] in the code that bombs. Then, try to bomb your webapp again. If it no longer bombs, then you are probably done: congratulations. If it still bombs, you might have missed a use of ImageIO: look again, re-wrap and re-try. If that does not work, we could use some more information about your environment. IIRC, you have installed Tomcat 7.0.40 including the bundled tcnative library, on Microsoft Windows in a directory called Tomcat 5.5 because of some hard-coded paths. So, everything is TC7.0.40, the library is statically-linked, and the tcnative version is 1.2.27. Can you confirm the above and also confirm the versions of tcnative, APR, and OpenSSL you have? They should all be displayed in your catalina.out log file (or wherever stdout goes when you launch Tomcat) near the beginning of the output after a fresh TC launch. If you are in production and just want to stop crashing, then you should switch connectors: use either the BIO or NIO connectors and you should avoid the fatal crash that occurs when the native stream has (likely) been closed and nulled-out. - -chris [1] http://wiki.apache.org/tomcat/FAQ/KnownIssues#ImageIOIssues -BEGIN PGP SIGNATURE- Version: GnuPG/MacGPG2 v2.0.17 (Darwin) Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBCAAGBQJRm8GxAAoJEBzwKT+lPKRYg6kP/3WHQ6+iWjqxo4VEhKio0vos fvY7YBu3LOGg0Yu0h1Flvl26JNo+iAW4fl+KsAetZVZQFX3GBV7mN4meKh5GuS60 ft3eu9fXL+i0oPQUyy4m4IK2RmuBbMSNp0f9q0MtifRpIOlyW4/XfcLesgiFsOxM dLHoWFYppDwW812x7zdjCzSZxlvNgVhPPnO9UipfM4oGMH5FSqTe/c19Omi7s4gv La2WpRSF2QDAQ5ldEXfblsOd2fSo8nDJEkJ7MwYb60/w6eEmxxJO2Y+NZfesA9wU HXXqUcNevU0CsiEsE4Ji05CzHPgNg+EGsaAYhjeZSVkdmBl6frm40SuKAe5c7rVc mRPgq5TyHnvr46ypar6vWoxaF4HVl0vNRgc1/jGE3y2WdCFBRm3K8wVWFGzrYaRd 1bbeyXxsEsxlkt8YvaL4/IXrvqOV9zhh1N9WuiR2lV5f4rWxwnBzX96J2VhA6/CI JyIeSl+f8G7Bm7H/Ey0Vxz97lq1iDWB6W+V4psKksXzgdghOh5TagnVg1mOW7ZC2 mGuCffu5bQcbW8hwmAZhMBbUujxGOupSAyrlBezFR2iCLOMrMQq38dmHW6juG440 APhCun1hiLENNAFsfmn3YvQXawG30hEs1jdZpJ91iJjHwQkIaKviJEvLkK1svMAt jFIkQ8854CUckhcWLYnS =Uu3w -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Apache Tomcat service has been shutting down/stopping randomly.
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 All, On 5/21/13 1:25 PM, James Snider wrote: [error occurred during error reporting (printing native stack), id 0xc005] Java frames: (J=compiled Java code, j=interpreted, Vv=VM code) j org.apache.tomcat.jni.Socket.sendbb(JII)I+0 The only line of code in Socket.sendbb that could possibly(*) be causing a SEGV is this one: ss = (*s-net-send)(s-opaque, s-jsbbuff + offset + sent, wr); Both s-opaque and s-jsbuff have been null-checked via assertions(*) so only s-net or s-net-send could be null. I don't know enough about how tcnative works with APR to know which one is more likely, or whether this is a safe-fail situation (because some wrapper data has been blanked-out and discarded) or if it is a potential security problem (overwriting a later response). - -chris * The assertions themselves could be causing a problem, as they look like this: TCN_ASSERT(s-opaque != NULL); TCN_ASSERT(s-jsbbuff != NULL); So, if s is null, it could cause the seg fault. Since s is passed-in from Java code (it's a jint), it probably should be checked for NULL before dereferencing it. - -chris -BEGIN PGP SIGNATURE- Version: GnuPG/MacGPG2 v2.0.17 (Darwin) Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBCAAGBQJRm8Q0AAoJEBzwKT+lPKRYVjkQAMLlB3MXl4YBdTVR2nHLPyH6 SeTgIFY+kzHkr9HikIcKcAEa+qO5K2WcnR0qBfSwzkDcWQZmt5cK15XEV2BDP7dB WbKyvIOAouh5dKMbNWlGjDwPb2+jp2YZ5Z3e/4GHRhv0HYHi17MRHxKx0ngg+JW4 SKk4uN5A6WXbXgNdwirnEYpJFjaSbhd+QWy6sm5mkygJ6zJ3+lBSOch2uJTSwGhg gadmlihn9027ZMFPX78UYLq6nopjuUK5MrrEKMQedlP4zEzkW8nNrVZVM2rkbzuU WbEWeqFSAUKSSsNAfsKek5vhFtc5dFXylmbiMeLMeu8y7Zl/3o/odmpzNGdxmDva o0GtKkihmf1i3Oz29ZMLU2EOmT2CQoyn2R+FeBLnOjTvg9EPdzN5O6rJcKY8EpNr oub+TpK+8q/ktWo7ZgqS0lREnLqP7rY/cRCc+IYjnq1ir7SS9sb2i8E3uGWTzi2U sZZY+uu5BlrmUAefPwra0XSRo4LFTrCafdnpTrg6twm6PTA6v0+N4kE7OD3v1keo JPQ+a9nu/oHwxhQ+tIIZe+pwwiKAQWyYBPDwU9P/LdE7vFF5tOdLKELBOrftfVEa atpBg8MaeGmnPLUpYZ1pQEjStaLNxFbvJSeEXbLGd7CoR3EUO+I4XshokaiRfPsv +lExhvHRpnarZJ+G7eew =uA/r -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Follow-up: Possible false-postive with JreMemoryLeakPreventionListener and Tomcat's JDBC Pool and OracleTimeoutPollingThread
On 21/05/2013 19:47, Michael-O wrote: Am 2013-05-21 20:38, schrieb Mark Thomas: Seems like they understood the problem. But I do doubt that this is a fixed size moemory leak. I think the point they are trying to make is that it is only the first instance of the web application to be unloaded that will be pinned in memory. Subsequent reloads won't trigger a leak. That is correct. Does this mean that only one WebAppClassLoader stays in memory because the thread is launched once and attached to that class loader? Exactly. Mark - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Apache Tomcat service has been shutting down/stopping randomly.
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
All,
On 5/21/13 3:00 PM, Christopher Schultz wrote:
All,
On 5/21/13 1:25 PM, James Snider wrote:
[error occurred during error reporting (printing native stack),
id 0xc005]
Java frames: (J=compiled Java code, j=interpreted, Vv=VM code) j
org.apache.tomcat.jni.Socket.sendbb(JII)I+0
The only line of code in Socket.sendbb that could possibly(*) be
causing a SEGV is this one:
ss = (*s-net-send)(s-opaque, s-jsbbuff + offset + sent, wr);
Both s-opaque and s-jsbuff have been null-checked via
assertions(*) so only s-net or s-net-send could be null.
s-net is set to NULL when destroy or close are called, so it's
plausible that this is the problem. What I didn't see what there was a
null-check against the jint sock parameter independent of the
cast-to-tcn_socket_t.
tcn_socket_t.net is this structure:
typedef struct {
int type;
apr_status_t (*cleanup)(void *);
apr_status_t (APR_THREAD_FUNC *close) (apr_socket_t *);
apr_status_t (APR_THREAD_FUNC *shutdown) (apr_socket_t *,
apr_shutdown_how_e);
apr_status_t (APR_THREAD_FUNC *opt_get)(apr_socket_t *,
apr_int32_t, apr_int32_t *);
apr_status_t (APR_THREAD_FUNC *opt_set)(apr_socket_t *,
apr_int32_t, apr_int32_t);
apr_status_t (APR_THREAD_FUNC *timeout_get)(apr_socket_t *,
apr_interval_time_t *);
apr_status_t (APR_THREAD_FUNC *timeout_set)(apr_socket_t *,
apr_interval_time_t);
apr_status_t (APR_THREAD_FUNC *send) (apr_socket_t *, const char
*, apr_size_t *);
apr_status_t (APR_THREAD_FUNC *sendv)(apr_socket_t *, const struct
iovec *, apr_int32_t, apr_size_t *);
apr_status_t (APR_THREAD_FUNC *recv) (apr_socket_t *, char *,
apr_size_t *);
} tcn_nlayer_t;
On a 64-bit architecture, the send pointer will be at offset=8*8 =
64d or 0x40, which is exactly the offset reported for the SEGV in the
core dump:
siginfo: ExceptionCode=0xc005, reading address 0x0040
It looks like we need another NULL check for s-net before attempting
to send data to the socket.
* The assertions themselves could be causing a problem, as they
look like this:
TCN_ASSERT(s-opaque != NULL); TCN_ASSERT(s-jsbbuff != NULL);
So, if s is null, it could cause the seg fault. Since s is
passed-in from Java code (it's a jint), it probably should be
checked for NULL before dereferencing it.
The win32 build of tcnative is unlikely to be in DEBUG mode, so the
TCN_ASSERTs end up being no-ops.
- -chris
-BEGIN PGP SIGNATURE-
Version: GnuPG/MacGPG2 v2.0.17 (Darwin)
Comment: GPGTools - http://gpgtools.org
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
iQIcBAEBCAAGBQJRm8d7AAoJEBzwKT+lPKRYD5AP/1JsceHfMdJIksp6KTthSQ+b
RuOot3r4It0EPAERaUHleIpw5h/0xZ3RJ8q6ZU1wy43g0JzUse7jm2dDR9vkfldg
rxDStLeyLnnvPFdo117akgQRA4ix4hKaIzP21Qvud9CA1B9h99DODZhfVqxJcU/C
pDFzOumlvt8yRBCfJuC6g9yqEmjoSf2m0FObRxbQQBY4TYceWFu3uoP5f5VCWYOd
hePerYh5wtkBaIgDJBVgUd1TJx36+sirlNBcVCxTL3SPy5BwumuomWT+jJnAxW+C
qr2IrLPnRlBVtnwJYU83RZlM3sqsZKpk/fz0PS7pe8SEKBmIZegijQRmyuN/o6VE
6AE6+uLqjIiRpK7ZkF3W0qZ9uOl1I2Flpg74yRQ0BxZZJhNqnmTCRtMUqlgHWRZ8
vpm6Tkb5gyPpQ0kggoVaoFy4vEEqhVPE2kiw00ESjmWxjjNBEW4qf33QGHs5LFKz
+OXQQmMG+WVxFzS4UpbkvTELKitKzDOWm2MYwNSiYZtdvZOyR/nUZ+B8IklcNIw/
3pVXM7++VK6IQN1rHz6UUhFVx2xsJ89qn0FENbmvdmJHgXsguPz8YhPlCnJZl4GH
wzsfsyJCNOT0W10eUIUyVNgVMNesvZQLVKYdi7fQlbFAOtkvUkUmOJusFF0850s9
cqSvvuZ3ei6Qj6XyfXw9
=LAjP
-END PGP SIGNATURE-
-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
RE: Where is a good SSL/TLS
Sorry, mouse got away from me. -Original Message- From: Caldarale, Charles R [mailto:chuck.caldar...@unisys.com] Sent: Tuesday, May 21, 2013 11:40 AM To: Tomcat Users List Subject: RE: Where is a good SSL/TLS From: Smith, Burton [mailto:burton.sm...@williams.com] Subject: Where is a good SSL/TLS I've been trying to figure out how to compile Apache 2.2 So wouldn't it be more effective to ask on the httpd mailing list rather than the Tomcat one? - Chuck THIS COMMUNICATION MAY CONTAIN CONFIDENTIAL AND/OR OTHERWISE PROPRIETARY MATERIAL and is thus for use only by the intended recipient. If you received this in error, please contact the sender and delete the e-mail and its attachments from all computers. - 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
Logging JIoEndpoint for Http11Protocol
Hi,
We are using tomcat 6.0.28, our goal is to figure out are we maxing out on
number of threads and I am looking at JIoEndpiont.java source code and found
the following code. So, looks like JIoEndpoint logs whenever all the worker
threads are busy, if i receive conncurrent connections more than maxThreads in
server.xml , i should see this logging message in catalina.out. So, how do i
enable the logs for this class org.apache.tomcat.util.net.JIoEndpoint.
if (curThreadsBusy == maxThreads) {
log.info(sm.getString(endpoint.info.maxThreads,
Integer.toString(maxThreads), address,
Integer.toString(port)));
}
I modified the following logging file: tomcat/conf/logging.properties, added
this entry to this file and bounced the server.
cat /usr/Interwoven/tomcat/conf/logging.properties | grep -A 4 -B 3 JIo
org.apache.catalina.core.ContainerBase.[Catalina].[localhost].[/host-manager].level
= INFO
org.apache.catalina.core.ContainerBase.[Catalina].[localhost].[/host-manager].handlers
= 5host-manager.org.apache.juli.FileHandler
org.apache.tomcat.util.net.JIoEndpoint.level = FINE
# For example, set the com.xyz.foo logger to only log SEVERE
# messages:
#org.apache.catalina.startup.ContextConfig.level = FINE
I also configured the server.xml as follows:
Connector
port=1776
maxThreads=8
threadPriority=MAX_PRIORITY
minSpareThreads=3
maxSpareThreads=5
enableLookups=false
acceptCount=512
debug=0
connectionTimeout=2
useURIValidationHack=false
disableUploadTimeout=true
URIEncoding=UTF-8/
Then, i ran the test as follows which generates 500 concurrent request, as
there are only 8 max threads, i should get log message that all threads are
busy.
ab -n 1000 -c 500 http://localhost:1776/test.
In theory i should see the log message if i configured everything correctly.
So do you have any idea on what am i missing here. How do i see the logging for
JIoEndpoint class ?
Any insights would be helpful.
Thanks,
Ravi
Re: Performance Issue while upgrading from Embedded Tomcat 6 to Tomcat 7
Hi Chris, I was monitoring the CPU utilization specifically. I can compromise on 1 less transactions/sec,but 80-90% utilization is not good. I tested the Async Servlet and the Hello World Servlet with the same environment and the client. Hello world servlet gave 20k req/sec and on the other hand Async Servlet was only 100 req/sec even less during the course. Both the results with 100 threads. I have configured 1000 max threads in the connector,and I am testing with 100 concurrent threads. Well I tested a sample html page with Tomcat 6.0.18 and 7.0.30 on Solaris x86 server. The req/sec were almost the same for both,but CPU utilization for Tomcat 6 was 23-27% and for Tomcat 7 it was 80-90% consistently. On the other hand on a Linux system,the req/sec were a little higher in Tomcat 7 say 65k to 55k on tomcat 6 and the CPU utilization was the same for both 6 and 7. My Jprofiler stack trace on Solaris is a lot different. As far as I have observed,for Tomcat 7 the stack Trace leads me to ResponseFacade.setContentType,which was not the behaviour in Tomcat 6. Can that be a bottleneck? Or is there something platform dependent that I should take care of? Thanks. From: Christopher Schultz ch...@christopherschultz.net To: Tomcat Users List users@tomcat.apache.org Sent: Tuesday, 21 May 2013 9:08 PM Subject: Re: Performance Issue while upgrading from Embedded Tomcat 6 to Tomcat 7 -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Chirag, On 5/20/13 10:38 AM, Chirag Dewan wrote: I ran my test client on Hello World example servlet on Tomcat 7.0.30. It was 12K req/sec with 80% CPU utilization. The same test case on tomcat 6.0.18 gave me similar req/sec but CPU utilization of 70% . The results on my linux server,with client and server running on the same machine. But all I am doing is comparing the 2 instances in the same environement. Running both client and server on the same machine is not a great test if you want to determine the server load by looking at CPU utilization. Were you looking at overall CPU utilization, or just utilization of the Tomcat JVM process? I am pretty sure the utilization is due to the server. The Jprofiler shows a lot of logging threads in tomcat consuming a lot of memory. Something I should be careful about? Can you be more specific? AFAIK, there are no logging threads in Tomcat at all. Also I ran an asynchronous servlet with the same client. The trans/sec reduced drastically,but the CPU utilization was only 4% I would expect a small reduction in trans/sec when using async, but nothing I would describe as drastic. Can you give us some numbers? Are there too may threads waiting for connection? Would thread pooling help, if we can? I think you mean too many connections waiting for a thread instead of the other way around. Threads are already pooled. What are your Connector configuration details, and what are the parameters for your load test? If you only have 10 connections configured, launching 10,000 clients isn't exactly a fair test. - -chris -BEGIN PGP SIGNATURE- Version: GnuPG/MacGPG2 v2.0.17 (Darwin) Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBCAAGBQJRm5UNAAoJEBzwKT+lPKRYKoEQAJeWY07c4jr1prAqvdrOyR4X X9CaWrZ4DwvsKuSn2NtZgXqf5lcLhsDzgP3Ej6cNhBx7WcK6zy8zpTZ2RdVo+YOB 1fGfdpZ6rMODT3i2UI8mAQmbG54NwA4C40ShsTpYVtdXb4GfAX+81j8HqtClr5Tf NEBq2xu4LJDc0ajE4mh+Vyr3M3wUG5CEsQAKhj3Owddtus6sltbrBs8116ZzcpQt 10COnt/e08ikyUVuAYxGZPvQ+rwhlFWuvTf0NlG9/oZSDxSb19KcdZ+vMi2HTNQr McQpVxd2RtqpTgM2NJ3uTS6rQ7R4I1moP96DOgNrU6jS2u5sJVoH98weq4AU4uxa 5sXJG4N4eaVsaFE9m2Nio3zgXZDObmF2jh1df79d7TzHkcIJHjtbZ9VHf1gLVqoW v2pWVU+7di6MiDg7P1Y8y2pXwYYF13ZVx6uozyfv6hGuGXDZkMmmg0QatpKguVXl sO3idan5klic3RJJg2zduq6PUlJZyqJJulqJas1DoUHARo6pSDkZWy1hYZQC9BGT dHgmxrA4Jo5Npq1VpiNMCXl/wCT2vKdsseqsCEQN4EIvgJWuZ5l8NkZtceQTPXtE 4CEcsSd83hIDmichkhVw3PoNHKSSFGwdRRI5sEXqW1Vv88Vj7ldtD8518vJUoQLu s2xIFlQjkJKW/W46Y+on =2P5W -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
RE: Performance Issue while upgrading from Embedded Tomcat 6 to Tomcat 7
From: Chirag Dewan [mailto:chirag.dewa...@yahoo.in] Subject: Re: Performance Issue while upgrading from Embedded Tomcat 6 to Tomcat 7 Well I tested a sample html page with Tomcat 6.0.18 and 7.0.30 on Solaris x86 server. The req/sec were almost the same for both, but CPU utilization for Tomcat 6 was 23-27% and for Tomcat 7 it was 80-90% consistently. With the exact same JVM for both Tomcat 6 and 7? (32- versus 64-bit, client versus server mode?) On the other hand on a Linux system,the req/sec were a little higher in Tomcat 7 say 65k to 55k on tomcat 6 and the CPU utilization was the same for both 6 and 7. With same JVM as on the Solaris box? (Again, 32- versus 64-bit, client versus server mode?) On the face of it, it sounds like a problem in the Solaris JVM. - Chuck THIS COMMUNICATION MAY CONTAIN CONFIDENTIAL AND/OR OTHERWISE PROPRIETARY MATERIAL and is thus for use only by the intended recipient. If you received this in error, please contact the sender and delete the e-mail and its attachments from all computers. - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: RE: Performance Issue while upgrading from Embedded Tomcat 6 to Tomcat 7
Yes. With same JVM on both Solaris and Linux i.e Java 1.6.39. It is 64 bit version. Thanks. Sent from Yahoo! Mail on Android
