tomcat reload single application command
Hi All, Can someone tell me how to reload one application of tomcat in the command line ? Best Regards, Ansir Hu
Thomas MC-GOWAN est absent.
Je serai absent(e) du 12/04/2013 au 06/05/2013.
Re: tomcat reload single application command
Hi, 2013/4/15 naouguh_tomcat wrote: Hi All, Can someone tell me how to reload one application of tomcat in the command line ? Please check this [1]. Regards Violeta [1] http://tomcat.10.x6.nabble.com/Command-line-reloading-of-a-webapp-td2038007.html
Re: Tomcat web application stops automatically
Rishad Ali wrote: I have a dedicated server running CentOS 5.9, Apache-Tomcat 5.5.36. I have written a JAVA web applications which runs every minute to collect the data from multiple sensors. I am using ScheduledExecutorService to execute the threads. (one thread for each sensor every minute and there can be more than hundred sensors) The flow of the thread is 1.Collect sensor information from the database. 2.Sends the command to the instrument to collect data. 3.Update the database with the data values. There is another application that checks the database every minute and send the alerts to the users (if necessary). I have monitored the application using jvisualVM, I cant find any memory leak. for every thread. The applications work fine but after some time(24 Hour - 48 Hours) the applications stop working. I can't find out what the problem could be, is it server configuration problem, too many threads or what? This might not be a Tomcat server problem but this could be Does anyone have any idea what might be going wrong or is there anyone who has done think kind of work? Please help, Thanks [.. snip .. ] This may be a naive question, but from your description above it is not clear if any of these applications have anything to do with Tomcat, or with a webserver environment. Why would it/they be running inside Tomcat ? - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Tomcat access log reveals hack attempt: HEAD /manager/html HTTP/1.0 404
On 15/04/2013 00:03, Christopher Schultz wrote: Pid, On 4/12/13 1:54 PM, Pïd stèr wrote: On 11 Apr 2013, at 21:36, Christopher Schultz ch...@christopherschultz.net wrote: [...] though I would run Apache httpd and Tomcat on different hosts, so localhost-binding is not possible unless you are doing something like stunnel (which also might be a good idea if you are traversing an untrusted network). Respectfully, I have to disagree. Unless the Apache HTTPD is loaded with IDS that can sniff the inbound traffic, you've not achieved much, and now you have two boxes that have to be maintained, secured patched. HTTPD != firewall. While httpd != firewall, it's traditional to allow external-access to your web server but not your app servers (databases, etc.). That means that external threats can only directly-attack the web server. Respectfully, this is clearly not true if you are just passing traffic to the app server. An attack that compromises the application server in the way described above would still be effective regardless of the presence of HTTPD. The risk I perceive is that users think that simply installing HTTPD somehow improves their security, when it does not. The 'traditional' approach in these matters needs close scrutiny IMO. People can't afford to rely on received wisdom for security and forget more important basics such as regular patching. I regularly debate this with customers and we usually agree/find a better approach. Obviously, suffering a web server break-in sucks, but at least the attacker then needs to break-into the application server after that. Why would they bother if they can attack the applications directly anyway? If it's a one-box wonder, you've been owned in a one fell swoop. A bit like this one, then. Also, running a heterogeneous environment can thwart attackers who have some kind of zero-day that got them into the web server (e.g. running httpd on Linux). Then they try the app server and surprise! It's NetBSD and they have to stop and find another attack to proceed. This is of course possible, but in practice quite rare. p -chris - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org -- [key:62590808] - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Tomcat access log reveals hack attempt: HEAD /manager/html HTTP/1.0 404
On 15/04/2013 03:51, Esmond Pitt wrote: I agree with your comment. Adding a second box for Tomcat only means I also have to configure a firewall between them, whereas using 127.0.0.x for Tomcat protects it completely. No it doesn't! Obfuscation or indirection != security. HTTPD doesn't magically provide you with some extra security capability. I don't know what you're talking about. I didn't mention HTTPD in the message you quoted. I mentioned 127.0.0.x, and it does exactly what I said it does. There is no 'security via obscurity' here, just a well-known TCP mechanism. I quote: We: - Hid the Tomcat behind an Apache HTTPD on port 80. You used the word 'hid'. ob·scure Adjective Not discovered or known about; uncertain. Verb Keep from being seen; conceal. Security via obscurity. - Closed port 8080, indeed removed all the HTTP Connectors from Tomcat and just used AJP connectors running on 127.0.0.1/2/3/4/..., all on the same port for simplicity, so there is no zero direct access to Tomcat from the outside I am objecting to the above as being an improvement on two counts: 1. the phrase 'direct access' has no meaning here 2. Tomcat still processes the bytes received from the client with no prior inspection or validation of their safety. - Configured Apache HTTPD for LDAP authentication via an OpenLDAP server that in turn is configured via the Password Policy overlay for finite (5 I think) password retries before locking out the account - required a very restricted LDAP group membership for access to /manager (and the other Tomcat builtins). So you secured the Manager app, rather than use a password that could be guessed. No recurrence, not even an attempt. I think actually closing port 8080 may have played the biggest part in all this. No it didn't. Using a password that couldn't be guessed did. p -- [key:62590808] - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
RE: Tomcat web application stops automatically
These application are running inside tomcat because I was under the impression that Tomcat is an application server and I need tomcat to run Java dynamic web applications. -Original Message- From: André Warnier [mailto:a...@ice-sa.com] Sent: 15 April 2013 11:14 To: Tomcat Users List Subject: Re: Tomcat web application stops automatically Rishad Ali wrote: I have a dedicated server running CentOS 5.9, Apache-Tomcat 5.5.36. I have written a JAVA web applications which runs every minute to collect the data from multiple sensors. I am using ScheduledExecutorService to execute the threads. (one thread for each sensor every minute and there can be more than hundred sensors) The flow of the thread is 1.Collect sensor information from the database. 2.Sends the command to the instrument to collect data. 3.Update the database with the data values. There is another application that checks the database every minute and send the alerts to the users (if necessary). I have monitored the application using jvisualVM, I cant find any memory leak. for every thread. The applications work fine but after some time(24 Hour - 48 Hours) the applications stop working. I can't find out what the problem could be, is it server configuration problem, too many threads or what? This might not be a Tomcat server problem but this could be Does anyone have any idea what might be going wrong or is there anyone who has done think kind of work? Please help, Thanks [.. snip .. ] This may be a naive question, but from your description above it is not clear if any of these applications have anything to do with Tomcat, or with a webserver environment. Why would it/they be running inside Tomcat ? - 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: Tomcat access log reveals hack attempt: HEAD /manager/html HTTP/1.0 404
When you quote me in refutation, kindly quote *all* and *only* the parts that are relevant. You have now made both mistakes in succession. I hid the Tomcat behind an HTTPD on port 80, closed port 8080, and made the Tomcat listen on 127.0.0.x only. A TCP socket that listens on 127.0.0.1 cannot be connected to from outside the localhost. That's not 'security by obscurity', that's security via a well-known feature of TCP. It is in effect a firewall. EJP -Original Message- From: Pid [mailto:p...@pidster.com] Sent: Monday, 15 April 2013 8:25 PM To: Esmond Pitt Cc: 'Tomcat Users List' Subject: Re: Tomcat access log reveals hack attempt: HEAD /manager/html HTTP/1.0 404 On 15/04/2013 03:51, Esmond Pitt wrote: I agree with your comment. Adding a second box for Tomcat only means I also have to configure a firewall between them, whereas using 127.0.0.x for Tomcat protects it completely. No it doesn't! Obfuscation or indirection != security. HTTPD doesn't magically provide you with some extra security capability. I don't know what you're talking about. I didn't mention HTTPD in the message you quoted. I mentioned 127.0.0.x, and it does exactly what I said it does. There is no 'security via obscurity' here, just a well-known TCP mechanism. I quote: We: - Hid the Tomcat behind an Apache HTTPD on port 80. You used the word 'hid'. ob.scure Adjective Not discovered or known about; uncertain. Verb Keep from being seen; conceal. Security via obscurity. - Closed port 8080, indeed removed all the HTTP Connectors from Tomcat and just used AJP connectors running on 127.0.0.1/2/3/4/..., all on the same port for simplicity, so there is no zero direct access to Tomcat from the outside I am objecting to the above as being an improvement on two counts: 1. the phrase 'direct access' has no meaning here 2. Tomcat still processes the bytes received from the client with no prior inspection or validation of their safety. - Configured Apache HTTPD for LDAP authentication via an OpenLDAP server that in turn is configured via the Password Policy overlay for finite (5 I think) password retries before locking out the account - required a very restricted LDAP group membership for access to /manager (and the other Tomcat builtins). So you secured the Manager app, rather than use a password that could be guessed. No recurrence, not even an attempt. I think actually closing port 8080 may have played the biggest part in all this. No it didn't. Using a password that couldn't be guessed did. p -- [key:62590808] - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Tomcat 5.0.28 documentation
Hi, I am searching for Tomcat 5.0.28 documentation in old mail archives and searching in web. But still I am not finding that. The reason to find this old documentation is, our application developed long back and its working in Tomcat 5.0.28 only. Kindly help on this. Regards, Eashwar.
Re: Re : Memory leak in Tomcat 6.0.35 ( 64 bit)
On 4/14/2013 11:10 PM, Howard W. Smith, Jr. wrote: On Sun, Apr 14, 2013 at 10:52 PM, Mark Thomasma...@apache.org wrote: On 14/04/2013 21:53, Howard W. Smith, Jr. wrote: On Sun, Apr 14, 2013 at 6:51 PM, Christopher Schultz ch...@christopherschultz.net wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Howard, On 4/11/13 10:38 PM, Howard W. Smith, Jr. wrote: On Thu, Apr 4, 2013 at 2:32 PM, Christopher Schultz ch...@christopherschultz.net wrote: Your heap settings should be tailored to your environment and usage scenarios. Interesting. I suppose 'your environment' means memory available, operating system, hardware. Usage scenarios? hmmm... please clarify with a brief example, thanks. :) Here's an example: Let's say that your webapp doesn't use HttpSessions and does no caching. You need to be able to handle 100 simultaneous connections that do small fetches/inserts from/into a relational database. Your pages are fairly simple and don't have any kind of heavyweight app framework taking-up a whole bunch of memory to do simple things. Thanks Chris for the example. This is definitely not my app. I am definitely relying on user HttpSessions, and I do JPA-level caching (statement cache and query results cache). pages are PrimeFaces and primefaces = xhtml, html, jquery, and MyFaces/OpenWebBeans to help with speed/performance. And right now, the app handles on a 'few' simultaneous connections/users that do small and large fetches/inserts from/into relational database. :) Hopefully one day, my app will be support 100+ simultaneous connections/users. For this situation, you can probably get away with a 64MiB heap. If your webapp uses more than 64MiB, there is probably some kind of problem. If you only need a 64MiB heap, then you can probably run on fairly modest hardware: there's no need to lease that 128GiB server your vendor is trying to talk you into. Understood, thanks. I have Xms/Xmx = 1024m, and I rarely see used memory get over 400 or 500m. the production server has 32GB RAM. I'll summarize a number of JavaOne sesisons I've been to on GC and performance (caveat - this was a couple of years ago and GC design has moved on since then). - GC pause time - throughput - small memory footprint You can optimise for any two of the above at the expense of the third. Assuming you opt for min GC pause time and max throughput the question then becomes how much heap do you need? If you look at your steady state heap usage graph (it should be a saw-tooth) then take the heap usage at the bottom of the saw-tooth and multiply it by 5 - that is the heap size you should use for the GC to work optimally. HTH, Mark Interesting, that does help, Mark, thanks. 250 x 5 = 1,250. I guess I was pretty close on target when I set Xms/Xmx = 1024m. Prior to seeing your email/response, I checked the server again, and it was no saw-tooth at all, it was at 250 (bottom), and then saw-tooth graph came into play...minutes later. Make sure you give it enough time for the memory use to stabilize. Depending on your app and usage patterns, it can take up to days for the sawtooth to stabilize and start showing. One of mine takes a couple of hours, and another a few days for that pattern to become visible. - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Tomcat access log reveals hack attempt: HEAD /manager/html HTTP/1.0 404
On 15/04/2013 11:36, Esmond Pitt wrote: When you quote me in refutation, kindly quote *all* and *only* the parts that are relevant. You have now made both mistakes in succession. I hid the Tomcat behind an HTTPD on port 80, closed port 8080, and made the Tomcat listen on 127.0.0.x only. A TCP socket that listens on 127.0.0.1 cannot be connected to from outside the localhost. That's not 'security by obscurity', that's security via a well-known feature of TCP. Kindly don't top post. I replied to a thread, it's quite normal to use context from prior messages in the thread. I am clearly replying in the context of the thread. It is in effect a firewall. It is not a firewall. It is a reverse proxy. 127.0.0.x for Tomcat protects it completely. No it doesn't, for a number of reasons, not least of which being that you're still sending traffic to it from the network. I believe you are missing my point, or choosing not to address it. A client makes a connection to a server through a succession of devices, each of which is forwarding the TCP traffic to the next device. Simply adding another entry to that pipeline that only performs the same job of forwarding traffic onto another port (local or otherwise) does not provide an improvement in security. So even if Tomcat only listens on a localhost socket, when you provide a means for other devices to connect to it from the network without intercepting that traffic to check it is safe, you are entirely negating the security benefit you postulate. I think that the attack you referred to would still have occurred even with your new 'security' if a) the manager app remained visible to the outside world and b) you left the password as it was. You fixed your problem by either preventing access to the Manager from the outside world (perhaps by a mod_jk/mod_proxy_ajp mapping) or by changing the noddy password you were using; You did not fix it by 'hiding' Tomcat itself or removing traffic from port 8080. I'm persisting in this point because I don't want other users to continue believing the fallacy that 'hiding' Tomcat behind Apache HTTPD alone improves their security. p EJP -Original Message- From: Pid [mailto:p...@pidster.com] Sent: Monday, 15 April 2013 8:25 PM To: Esmond Pitt Cc: 'Tomcat Users List' Subject: Re: Tomcat access log reveals hack attempt: HEAD /manager/html HTTP/1.0 404 On 15/04/2013 03:51, Esmond Pitt wrote: I agree with your comment. Adding a second box for Tomcat only means I also have to configure a firewall between them, whereas using 127.0.0.x for Tomcat protects it completely. No it doesn't! Obfuscation or indirection != security. HTTPD doesn't magically provide you with some extra security capability. I don't know what you're talking about. I didn't mention HTTPD in the message you quoted. I mentioned 127.0.0.x, and it does exactly what I said it does. There is no 'security via obscurity' here, just a well-known TCP mechanism. I quote: We: - Hid the Tomcat behind an Apache HTTPD on port 80. You used the word 'hid'. ob.scure Adjective Not discovered or known about; uncertain. Verb Keep from being seen; conceal. Security via obscurity. - Closed port 8080, indeed removed all the HTTP Connectors from Tomcat and just used AJP connectors running on 127.0.0.1/2/3/4/..., all on the same port for simplicity, so there is no zero direct access to Tomcat from the outside I am objecting to the above as being an improvement on two counts: 1. the phrase 'direct access' has no meaning here 2. Tomcat still processes the bytes received from the client with no prior inspection or validation of their safety. - Configured Apache HTTPD for LDAP authentication via an OpenLDAP server that in turn is configured via the Password Policy overlay for finite (5 I think) password retries before locking out the account - required a very restricted LDAP group membership for access to /manager (and the other Tomcat builtins). So you secured the Manager app, rather than use a password that could be guessed. No recurrence, not even an attempt. I think actually closing port 8080 may have played the biggest part in all this. No it didn't. Using a password that couldn't be guessed did. p -- [key:62590808] - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: tomcat reload single application command
Why would you want to reload the application? What are the motives behind that? There are few ways to do it... it all depends what do you want to accomplish and what type of an app it... what is your current deployment procedure? Here are few ways: 1. Obvious one, remove app from webapps and copy it again. Automatic deployment will take care of it. 2. Use above mentioned method through the management app, using curl or wget tool to invoke the reload. 3. Similar method to 2, but using manager app jmxproxy servlet. 4. Writing your custom code to access jmx and call mbean to invoke deployment reload. Hope that helps...
Re: Tomcat 5.0.28 documentation
M Eashwar, On 15.4.2013 13:25, M Eashwar wrote: I am searching for Tomcat 5.0.28 documentation in old mail archives and searching in web. But still I am not finding that. The reason to find this old documentation is, our application developed long back and its working in Tomcat 5.0.28 only. Tomcat 5.x is unsupported, that is why you will have a hard time finding any documentation for that version. That is for a reason -- Tomcat 5.x is considered outdated and unsafe. Instead of digging old documentation, why don't you consider upgrade to latest Tomcat 7 version (7.0.39 at the moment)? It shouldn't be too hard to do it, especially with support from users on this mailing list. -Ognjen - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Tomcat web application stops automatically
Am 15.04.2013 11:31, schrieb Rishad Ali: I have a dedicated server running CentOS 5.9, Apache-Tomcat 5.5.36. I have written a JAVA web applications which runs every minute to collect the data from multiple sensors. I am using ScheduledExecutorService to execute the threads. (one thread for each sensor every minute and there can be more than hundred sensors) The flow of the thread is A web application can be deployed to tomcat and when it is deployed it can be running or not. It can't run every minute. snip/ thread. The applications work fine but after some time(24 Hour - 48 Hours) the applications stop working. I can't find out what the problem What does that mean? Did you take a look at the tomcat logfiles? Ralph - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
RE: Tomcat web application stops automatically
I think I mentioned this in the question that I am using ScheduledExecutorService to start threads every minute. This is not the application running every minute, these are the threads I create. And as I said It works fine for some time then it stops. Yes I checked the log but there is no sign of stopping application or nothing about Too many database connections. -Original Message- From: Ralph Plawetzki [mailto:ra...@purejava.org] Sent: 15 April 2013 13:11 To: Tomcat Users List Subject: Re: Tomcat web application stops automatically Am 15.04.2013 11:31, schrieb Rishad Ali: I have a dedicated server running CentOS 5.9, Apache-Tomcat 5.5.36. I have written a JAVA web applications which runs every minute to collect the data from multiple sensors. I am using ScheduledExecutorService to execute the threads. (one thread for each sensor every minute and there can be more than hundred sensors) The flow of the thread is A web application can be deployed to tomcat and when it is deployed it can be running or not. It can't run every minute. snip/ thread. The applications work fine but after some time(24 Hour - 48 Hours) the applications stop working. I can't find out what the problem What does that mean? Did you take a look at the tomcat logfiles? Ralph - 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: Tomcat web application stops automatically
Am 15.04.2013 14:22, schrieb Rishad Ali: I think I mentioned this in the question that I am using ScheduledExecutorService to start threads every minute. This is not the application running every minute, these are the threads I create. And as I said It works fine for some time then it stops. Yes I checked the log but there is no sign of stopping application or nothing about Too many database connections. Please don't top-post. When your application(s) stopped: take a thread dump and post it here. Ralph - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Tomcat access log reveals hack attempt: HEAD /manager/html HTTP/1.0 404
On Mon, Apr 15, 2013 at 7:49 AM, Pid p...@pidster.com wrote: I'm persisting in this point because I don't want other users to continue believing the fallacy that 'hiding' Tomcat behind Apache HTTPD alone improves their security. And your persistence is appreciated, and I definitely appreciate all the responses/discussion. :)
Re: Re : Memory leak in Tomcat 6.0.35 ( 64 bit)
On Mon, Apr 15, 2013 at 7:40 AM, David kerber dcker...@verizon.net wrote: On 4/14/2013 11:10 PM, Howard W. Smith, Jr. wrote: On Sun, Apr 14, 2013 at 10:52 PM, Mark Thomasma...@apache.org wrote: On 14/04/2013 21:53, Howard W. Smith, Jr. wrote: On Sun, Apr 14, 2013 at 6:51 PM, Christopher Schultz ch...@christopherschultz.net wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Howard, On 4/11/13 10:38 PM, Howard W. Smith, Jr. wrote: On Thu, Apr 4, 2013 at 2:32 PM, Christopher Schultz ch...@christopherschultz.net wrote: Your heap settings should be tailored to your environment and usage scenarios. Interesting. I suppose 'your environment' means memory available, operating system, hardware. Usage scenarios? hmmm... please clarify with a brief example, thanks. :) Here's an example: Let's say that your webapp doesn't use HttpSessions and does no caching. You need to be able to handle 100 simultaneous connections that do small fetches/inserts from/into a relational database. Your pages are fairly simple and don't have any kind of heavyweight app framework taking-up a whole bunch of memory to do simple things. Thanks Chris for the example. This is definitely not my app. I am definitely relying on user HttpSessions, and I do JPA-level caching (statement cache and query results cache). pages are PrimeFaces and primefaces = xhtml, html, jquery, and MyFaces/OpenWebBeans to help with speed/performance. And right now, the app handles on a 'few' simultaneous connections/users that do small and large fetches/inserts from/into relational database. :) Hopefully one day, my app will be support 100+ simultaneous connections/users. For this situation, you can probably get away with a 64MiB heap. If your webapp uses more than 64MiB, there is probably some kind of problem. If you only need a 64MiB heap, then you can probably run on fairly modest hardware: there's no need to lease that 128GiB server your vendor is trying to talk you into. Understood, thanks. I have Xms/Xmx = 1024m, and I rarely see used memory get over 400 or 500m. the production server has 32GB RAM. I'll summarize a number of JavaOne sesisons I've been to on GC and performance (caveat - this was a couple of years ago and GC design has moved on since then). - GC pause time - throughput - small memory footprint You can optimise for any two of the above at the expense of the third. Assuming you opt for min GC pause time and max throughput the question then becomes how much heap do you need? If you look at your steady state heap usage graph (it should be a saw-tooth) then take the heap usage at the bottom of the saw-tooth and multiply it by 5 - that is the heap size you should use for the GC to work optimally. HTH, Mark Interesting, that does help, Mark, thanks. 250 x 5 = 1,250. I guess I was pretty close on target when I set Xms/Xmx = 1024m. Prior to seeing your email/response, I checked the server again, and it was no saw-tooth at all, it was at 250 (bottom), and then saw-tooth graph came into play...minutes later. Make sure you give it enough time for the memory use to stabilize. Will do (and doing that), thanks. :) Depending on your app and usage patterns, it can take up to days for the sawtooth to stabilize and start showing. One of mine takes a couple of hours, and another a few days for that pattern to become visible. I see it stabilize 'in minutes' (after/during usage of the app). Just now (prior to writing this email), I was looking at the app's usage (via monitoring the app's own data/record audit trail page), and then decided to check-on the app to see how it is doing/performing via jvisualvm, and voila, again, I saw no saw-tooth[1]. I saw this, 5 to 15 minutes after a period of inactivity in the app, but before I logged into the app, as I stated above, I checked the app's audit trail (which can definitely be a 'heavy-lifting' database query, depending on work done within the app on selected date, default = current date), and it[1] still showed no activity (or saw-tooth); I assume activity within the app can = definite/obvious saw-tooth graph (which also means, GC is working while app is being used). What I mentioned above is very normal behavior for my app. [1] http://img805.imageshack.us/img805/8453/20130415jvisualvm01.png --**--**- 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 reload single application command
On 4/15/2013 12:54 AM, naouguh_tomcat wrote: Hi All, Can someone tell me how to reload one application of tomcat in the command line ? Best Regards, Ansir Hu I don't know which version of Tomcat you're running, so here's a reference to both currently active versions: http://tomcat.apache.org/tomcat-7.0-doc/manager-howto.html#Executing_Manager_Commands_With_Ant http://tomcat.apache.org/tomcat-6.0-doc/manager-howto.html#Executing_Manager_Commands_With_Ant See in particular: taskdef name=reload classname=org.apache.catalina.ant.ReloadTask/ Write an Ant script, run from the command line. . . . . just my two cents. /mde/ - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Re : Memory leak in Tomcat 6.0.35 ( 64 bit)
On 4/15/2013 10:10 AM, Howard W. Smith, Jr. wrote: On Mon, Apr 15, 2013 at 7:40 AM, David kerberdcker...@verizon.net wrote: On 4/14/2013 11:10 PM, Howard W. Smith, Jr. wrote: On Sun, Apr 14, 2013 at 10:52 PM, Mark Thomasma...@apache.org wrote: On 14/04/2013 21:53, Howard W. Smith, Jr. wrote: On Sun, Apr 14, 2013 at 6:51 PM, Christopher Schultz ch...@christopherschultz.net wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Howard, On 4/11/13 10:38 PM, Howard W. Smith, Jr. wrote: On Thu, Apr 4, 2013 at 2:32 PM, Christopher Schultz ch...@christopherschultz.net wrote: Your heap settings should be tailored to your environment and usage scenarios. Interesting. I suppose 'your environment' means memory available, operating system, hardware. Usage scenarios? hmmm... please clarify with a brief example, thanks. :) Here's an example: Let's say that your webapp doesn't use HttpSessions and does no caching. You need to be able to handle 100 simultaneous connections that do small fetches/inserts from/into a relational database. Your pages are fairly simple and don't have any kind of heavyweight app framework taking-up a whole bunch of memory to do simple things. Thanks Chris for the example. This is definitely not my app. I am definitely relying on user HttpSessions, and I do JPA-level caching (statement cache and query results cache). pages are PrimeFaces and primefaces = xhtml, html, jquery, and MyFaces/OpenWebBeans to help with speed/performance. And right now, the app handles on a 'few' simultaneous connections/users that do small and large fetches/inserts from/into relational database. :) Hopefully one day, my app will be support 100+ simultaneous connections/users. For this situation, you can probably get away with a 64MiB heap. If your webapp uses more than 64MiB, there is probably some kind of problem. If you only need a 64MiB heap, then you can probably run on fairly modest hardware: there's no need to lease that 128GiB server your vendor is trying to talk you into. Understood, thanks. I have Xms/Xmx = 1024m, and I rarely see used memory get over 400 or 500m. the production server has 32GB RAM. I'll summarize a number of JavaOne sesisons I've been to on GC and performance (caveat - this was a couple of years ago and GC design has moved on since then). - GC pause time - throughput - small memory footprint You can optimise for any two of the above at the expense of the third. Assuming you opt for min GC pause time and max throughput the question then becomes how much heap do you need? If you look at your steady state heap usage graph (it should be a saw-tooth) then take the heap usage at the bottom of the saw-tooth and multiply it by 5 - that is the heap size you should use for the GC to work optimally. HTH, Mark Interesting, that does help, Mark, thanks. 250 x 5 = 1,250. I guess I was pretty close on target when I set Xms/Xmx = 1024m. Prior to seeing your email/response, I checked the server again, and it was no saw-tooth at all, it was at 250 (bottom), and then saw-tooth graph came into play...minutes later. Make sure you give it enough time for the memory use to stabilize. Will do (and doing that), thanks. :) Depending on your app and usage patterns, it can take up to days for the sawtooth to stabilize and start showing. One of mine takes a couple of hours, and another a few days for that pattern to become visible. I see it stabilize 'in minutes' (after/during usage of the app). Just now (prior to writing this email), I was looking at the app's usage (via monitoring the app's own data/record audit trail page), and then decided to check-on the app to see how it is doing/performing via jvisualvm, and voila, again, I saw no saw-tooth[1]. I saw this, 5 to 15 minutes after a period of inactivity in the app, but before I logged into the app, as I stated above, I checked the app's audit trail (which can definitely be a 'heavy-lifting' database query, depending on work done within the app on selected date, default = current date), and it[1] still showed no activity (or saw-tooth); I assume activity within the app can = definite/obvious saw-tooth graph (which also means, GC is working while app is being used). What I mentioned above is very normal behavior for my app. [1] http://img805.imageshack.us/img805/8453/20130415jvisualvm01.png These graphs are only showing ~40 seconds of data. I'll bet if you let the app run for several minutes or hours, you'll see it. --**--**- To unsubscribe, e-mail: users-unsubscribe@tomcat.**apache.orgusers-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: Tomcat 5.0.28 documentation
On 4/15/2013 5:03 AM, Ognjen Blagojevic wrote: M Eashwar, On 15.4.2013 13:25, M Eashwar wrote: I am searching for Tomcat 5.0.28 documentation in old mail archives and searching in web. But still I am not finding that. The reason to find this old documentation is, our application developed long back and its working in Tomcat 5.0.28 only. Tomcat 5.x is unsupported, that is why you will have a hard time finding any documentation for that version. That is for a reason -- Tomcat 5.x is considered outdated and unsafe. Instead of digging old documentation, why don't you consider upgrade to latest Tomcat 7 version (7.0.39 at the moment)? It shouldn't be too hard to do it, especially with support from users on this mailing list. -Ognjen Agreed, far far better to upgrade. However if you must have a copy of Tomcat 5.0.28 (for historical purposes?), you could pull down the original from: http://archive.apache.org/dist/tomcat/ As Ognjen has pointed out, the likelihood of mailing list support for that version is pretty slim. . . . . just my two cents. /mde/ - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Tomcat access log reveals hack attempt: HEAD /manager/html HTTP/1.0 404
On 4/15/2013 3:19 AM, Pid wrote: On 15/04/2013 00:03, Christopher Schultz wrote: Pid, On 4/12/13 1:54 PM, Pïd stèr wrote: On 11 Apr 2013, at 21:36, Christopher Schultz ch...@christopherschultz.net wrote: [...] though I would run Apache httpd and Tomcat on different hosts, so localhost-binding is not possible unless you are doing something like stunnel (which also might be a good idea if you are traversing an untrusted network). Respectfully, I have to disagree. Unless the Apache HTTPD is loaded with IDS that can sniff the inbound traffic, you've not achieved much, and now you have two boxes that have to be maintained, secured patched. HTTPD != firewall. While httpd != firewall, it's traditional to allow external-access to your web server but not your app servers (databases, etc.). That means that external threats can only directly-attack the web server. Respectfully, this is clearly not true if you are just passing traffic to the app server. An attack that compromises the application server in the way described above would still be effective regardless of the presence of HTTPD. The risk I perceive is that users think that simply installing HTTPD somehow improves their security, when it does not. I guess we first need to agree what is meant by compromised. If you mean application-level compromise, then absolutely. Simply adding Apache HTTPD, multiple systems, firewalls with carefully crafted holes to allow proxying does little (possibly nothing?) to improve security. If you mean OS-level compromise (administrative access on a target machine), then these techniques can improve security. Of course, the security that this provides depends almost entirely on the underlying architecture and little on the fact that you're fronting Tomcat with HTTPD. One possible improvement in security afforded by running Tomcat behind HTTPD is the use of mod_security. While mod_security impacts performance and doesn't catch everything (currently JSON support is not at all good), it will help as a part of a systems security architecture. This turns Apache HTTPD into an IDS, which was mentioned a bit ago in this thread. The 'traditional' approach in these matters needs close scrutiny IMO. People can't afford to rely on received wisdom for security and forget more important basics such as regular patching. Regular patching, regular auditing of logs, regular testing, keep up on the relevant technology mailing lists. I really do not like the (prevalent?) attitude of if it aint broke, don't patch it. Well-architected systems don't (shouldn't) break when you patch components. If you find a lot of breakage, then you're looking at tightly coupled systems - in almost every case this is a Bad Thing (IMHO). I regularly debate this with customers and we usually agree/find a better approach. Obviously, suffering a web server break-in sucks, but at least the attacker then needs to break-into the application server after that. Why would they bother if they can attack the applications directly anyway? Again, this depends on the target. If by breaking the application you gain control of the application server or obtain PII (personally identifiable information), then this may be all that's desired. If you desire a beachhead to investigate / crack the target further, then usually OS-level access (and often, a privileged account) is needed. If it's a one-box wonder, you've been owned in a one fell swoop. A bit like this one, then. Also, running a heterogeneous environment can thwart attackers who have some kind of zero-day that got them into the web server (e.g. running httpd on Linux). Then they try the app server and surprise! It's NetBSD and they have to stop and find another attack to proceed. This is of course possible, but in practice quite rare. Agreed, operations likes same-ol', same-ol'. Running completely different architectures on different layers is usually not seen, unless the architecture has grown organically. If the infrastructure architecture has been grown organically, then there are likely other systemic problems. p -chris As mentioned earlier in this thread, I don't see the penchant for making the manager application internet-accessible. Sooner or later this can bite you hard. Setting up a VPN using OpenVPN is not that difficult. It's a little more difficult using two-factor authentication (PIN card plus certificate), but still doable. Then, set up a limited second connector HTTP connector (not many threads) to serve your manager application. Now you have a little more security. 1. Something you have (certificate) 2. Something you know (possible PIN, possible password on certificate) 3. Another something you know (how to access the manager application) 4. Reasonably secure (depending on how you set up OpenVPN) access 5. Audit trail (OpenVPN logs, manager logs) 6. Revocation ability (revoke OpenVPN certs, change manager access)
Re: Re : Memory leak in Tomcat 6.0.35 ( 64 bit)
On 4/15/2013 7:25 AM, David kerber wrote: On 4/15/2013 10:10 AM, Howard W. Smith, Jr. wrote: On Mon, Apr 15, 2013 at 7:40 AM, David kerberdcker...@verizon.net wrote: On 4/14/2013 11:10 PM, Howard W. Smith, Jr. wrote: On Sun, Apr 14, 2013 at 10:52 PM, Mark Thomasma...@apache.org wrote: On 14/04/2013 21:53, Howard W. Smith, Jr. wrote: On Sun, Apr 14, 2013 at 6:51 PM, Christopher Schultz ch...@christopherschultz.net wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Howard, On 4/11/13 10:38 PM, Howard W. Smith, Jr. wrote: On Thu, Apr 4, 2013 at 2:32 PM, Christopher Schultz ch...@christopherschultz.net wrote: Your heap settings should be tailored to your environment and usage scenarios. Interesting. I suppose 'your environment' means memory available, operating system, hardware. Usage scenarios? hmmm... please clarify with a brief example, thanks. :) Here's an example: Let's say that your webapp doesn't use HttpSessions and does no caching. You need to be able to handle 100 simultaneous connections that do small fetches/inserts from/into a relational database. Your pages are fairly simple and don't have any kind of heavyweight app framework taking-up a whole bunch of memory to do simple things. Thanks Chris for the example. This is definitely not my app. I am definitely relying on user HttpSessions, and I do JPA-level caching (statement cache and query results cache). pages are PrimeFaces and primefaces = xhtml, html, jquery, and MyFaces/OpenWebBeans to help with speed/performance. And right now, the app handles on a 'few' simultaneous connections/users that do small and large fetches/inserts from/into relational database. :) Hopefully one day, my app will be support 100+ simultaneous connections/users. For this situation, you can probably get away with a 64MiB heap. If your webapp uses more than 64MiB, there is probably some kind of problem. If you only need a 64MiB heap, then you can probably run on fairly modest hardware: there's no need to lease that 128GiB server your vendor is trying to talk you into. Understood, thanks. I have Xms/Xmx = 1024m, and I rarely see used memory get over 400 or 500m. the production server has 32GB RAM. I'll summarize a number of JavaOne sesisons I've been to on GC and performance (caveat - this was a couple of years ago and GC design has moved on since then). - GC pause time - throughput - small memory footprint You can optimise for any two of the above at the expense of the third. Assuming you opt for min GC pause time and max throughput the question then becomes how much heap do you need? If you look at your steady state heap usage graph (it should be a saw-tooth) then take the heap usage at the bottom of the saw-tooth and multiply it by 5 - that is the heap size you should use for the GC to work optimally. HTH, Mark Interesting, that does help, Mark, thanks. 250 x 5 = 1,250. I guess I was pretty close on target when I set Xms/Xmx = 1024m. Prior to seeing your email/response, I checked the server again, and it was no saw-tooth at all, it was at 250 (bottom), and then saw-tooth graph came into play...minutes later. Make sure you give it enough time for the memory use to stabilize. Will do (and doing that), thanks. :) Depending on your app and usage patterns, it can take up to days for the sawtooth to stabilize and start showing. One of mine takes a couple of hours, and another a few days for that pattern to become visible. I see it stabilize 'in minutes' (after/during usage of the app). Just now (prior to writing this email), I was looking at the app's usage (via monitoring the app's own data/record audit trail page), and then decided to check-on the app to see how it is doing/performing via jvisualvm, and voila, again, I saw no saw-tooth[1]. I saw this, 5 to 15 minutes after a period of inactivity in the app, but before I logged into the app, as I stated above, I checked the app's audit trail (which can definitely be a 'heavy-lifting' database query, depending on work done within the app on selected date, default = current date), and it[1] still showed no activity (or saw-tooth); I assume activity within the app can = definite/obvious saw-tooth graph (which also means, GC is working while app is being used). What I mentioned above is very normal behavior for my app. [1] http://img805.imageshack.us/img805/8453/20130415jvisualvm01.png These graphs are only showing ~40 seconds of data. I'll bet if you let the app run for several minutes or hours, you'll see it. Yep, there's no history in that data. What you can do (probably in a test environment) is the following: 1. Set up monitoring (visualvm, psi-probe, jconsole) 2. Abuse your application with well-crafted JMeter (or other) tests 3. Watch memory This becomes a little more challenging with AJAX-style applications (yours is a PrimeFaces / JSF / AJAX one, right?), but I've seen some notes on this. Google is your
Re: Tomcat access log reveals hack attempt: HEAD /manager/html HTTP/1.0 404
On 15/04/2013 16:11, Mark Eggers wrote: On 4/15/2013 3:19 AM, Pid wrote: On 15/04/2013 00:03, Christopher Schultz wrote: Pid, On 4/12/13 1:54 PM, Pïd stèr wrote: On 11 Apr 2013, at 21:36, Christopher Schultz ch...@christopherschultz.net wrote: [...] though I would run Apache httpd and Tomcat on different hosts, so localhost-binding is not possible unless you are doing something like stunnel (which also might be a good idea if you are traversing an untrusted network). Respectfully, I have to disagree. Unless the Apache HTTPD is loaded with IDS that can sniff the inbound traffic, you've not achieved much, and now you have two boxes that have to be maintained, secured patched. HTTPD != firewall. While httpd != firewall, it's traditional to allow external-access to your web server but not your app servers (databases, etc.). That means that external threats can only directly-attack the web server. Respectfully, this is clearly not true if you are just passing traffic to the app server. An attack that compromises the application server in the way described above would still be effective regardless of the presence of HTTPD. The risk I perceive is that users think that simply installing HTTPD somehow improves their security, when it does not. I guess we first need to agree what is meant by compromised. If you mean application-level compromise, then absolutely. Simply adding Apache HTTPD, multiple systems, firewalls with carefully crafted holes to allow proxying does little (possibly nothing?) to improve security. If you mean OS-level compromise (administrative access on a target machine), then these techniques can improve security. Of course, the security that this provides depends almost entirely on the underlying architecture and little on the fact that you're fronting Tomcat with HTTPD. One possible improvement in security afforded by running Tomcat behind HTTPD is the use of mod_security. While mod_security impacts performance and doesn't catch everything (currently JSON support is not at all good), it will help as a part of a systems security architecture. This turns Apache HTTPD into an IDS, which was mentioned a bit ago in this thread. (By me!) Agreed, adding mod_security could provide a reason to use HTTPD in front. The 'traditional' approach in these matters needs close scrutiny IMO. People can't afford to rely on received wisdom for security and forget more important basics such as regular patching. Regular patching, regular auditing of logs, regular testing, keep up on the relevant technology mailing lists. I really do not like the (prevalent?) attitude of if it aint broke, don't patch it. Well-architected systems don't (shouldn't) break when you patch components. If you find a lot of breakage, then you're looking at tightly coupled systems - in almost every case this is a Bad Thing (IMHO). I regularly debate this with customers and we usually agree/find a better approach. Obviously, suffering a web server break-in sucks, but at least the attacker then needs to break-into the application server after that. Why would they bother if they can attack the applications directly anyway? Again, this depends on the target. If by breaking the application you gain control of the application server or obtain PII (personally identifiable information), then this may be all that's desired. Look at the typical attack patterns described as being prevalent today, they are mass-produced, automated scripts probing IP after IP. They are not a single guy in a dark room working a keyboard. They are going for the LCD, for which the most part is unpatched systems. The zero-day vulnerabilities are saved for high-value targets and the occasional publicity generating show off. Most frequently they are just probing IP ranges and it's not *you* that's being targeted specifically, the attacker just wants to add another machine for their botnet. If you desire a beachhead to investigate / crack the target further, then usually OS-level access (and often, a privileged account) is needed. Yes, (assuming they are attacking you deliberately), to get this they will not attack your website, they will attempt to compromise your employees, starting with someone who is not IT literate getting them to open an email attachment that looks like it comes from a colleague. p If it's a one-box wonder, you've been owned in a one fell swoop. A bit like this one, then. Also, running a heterogeneous environment can thwart attackers who have some kind of zero-day that got them into the web server (e.g. running httpd on Linux). Then they try the app server and surprise! It's NetBSD and they have to stop and find another attack to proceed. This is of course possible, but in practice quite rare. Agreed, operations likes same-ol', same-ol'. Running completely different architectures on different layers is usually not seen, unless the
Re: Tomcat access log reveals hack attempt: HEAD /manager/html HTTP/1.0 404
Pid wrote: On 15/04/2013 11:36, Esmond Pitt wrote: When you quote me in refutation, kindly quote *all* and *only* the parts that are relevant. You have now made both mistakes in succession. I hid the Tomcat behind an HTTPD on port 80, closed port 8080, and made the Tomcat listen on 127.0.0.x only. A TCP socket that listens on 127.0.0.1 cannot be connected to from outside the localhost. That's not 'security by obscurity', that's security via a well-known feature of TCP. Kindly don't top post. I replied to a thread, it's quite normal to use context from prior messages in the thread. I am clearly replying in the context of the thread. It is in effect a firewall. It is not a firewall. It is a reverse proxy. 127.0.0.x for Tomcat protects it completely. No it doesn't, for a number of reasons, not least of which being that you're still sending traffic to it from the network. I believe you are missing my point, or choosing not to address it. A client makes a connection to a server through a succession of devices, each of which is forwarding the TCP traffic to the next device. Simply adding another entry to that pipeline that only performs the same job of forwarding traffic onto another port (local or otherwise) does not provide an improvement in security. So even if Tomcat only listens on a localhost socket, when you provide a means for other devices to connect to it from the network without intercepting that traffic to check it is safe, you are entirely negating the security benefit you postulate. I think that the attack you referred to would still have occurred even with your new 'security' if a) the manager app remained visible to the outside world and b) you left the password as it was. You fixed your problem by either preventing access to the Manager from the outside world (perhaps by a mod_jk/mod_proxy_ajp mapping) or by changing the noddy password you were using; You did not fix it by 'hiding' Tomcat itself or removing traffic from port 8080. I'm persisting in this point because I don't want other users to continue believing the fallacy that 'hiding' Tomcat behind Apache HTTPD alone improves their security. p EJP -Original Message- From: Pid [mailto:p...@pidster.com] Sent: Monday, 15 April 2013 8:25 PM To: Esmond Pitt Cc: 'Tomcat Users List' Subject: Re: Tomcat access log reveals hack attempt: HEAD /manager/html HTTP/1.0 404 On 15/04/2013 03:51, Esmond Pitt wrote: I agree with your comment. Adding a second box for Tomcat only means I also have to configure a firewall between them, whereas using 127.0.0.x for Tomcat protects it completely. No it doesn't! Obfuscation or indirection != security. HTTPD doesn't magically provide you with some extra security capability. I don't know what you're talking about. I didn't mention HTTPD in the message you quoted. I mentioned 127.0.0.x, and it does exactly what I said it does. There is no 'security via obscurity' here, just a well-known TCP mechanism. I quote: We: - Hid the Tomcat behind an Apache HTTPD on port 80. You used the word 'hid'. ob.scure Adjective Not discovered or known about; uncertain. Verb Keep from being seen; conceal. Security via obscurity. - Closed port 8080, indeed removed all the HTTP Connectors from Tomcat and just used AJP connectors running on 127.0.0.1/2/3/4/..., all on the same port for simplicity, so there is no zero direct access to Tomcat from the outside I am objecting to the above as being an improvement on two counts: 1. the phrase 'direct access' has no meaning here 2. Tomcat still processes the bytes received from the client with no prior inspection or validation of their safety. - Configured Apache HTTPD for LDAP authentication via an OpenLDAP server that in turn is configured via the Password Policy overlay for finite (5 I think) password retries before locking out the account - required a very restricted LDAP group membership for access to /manager (and the other Tomcat builtins). So you secured the Manager app, rather than use a password that could be guessed. No recurrence, not even an attempt. I think actually closing port 8080 may have played the biggest part in all this. No it didn't. Using a password that couldn't be guessed did. Maybe to bridge both interpretations here, and smooth the discussion a bit : In his original post, Esmond listed 5 points which *together* increased security for the access to the Manager application. And, as explained, they do. However, in subsequent comments he also seemed to imply that putting httpd in front of Tomcat, and restricting Tomcat access so that it could only be accessed through httpd, was in itself a security feature and a firewall. That is not the case, and that was what Pid objected to, as potentially able to confuse naive readers on this list. Esmond also mentioned that simply changing the port through which Tomcat was being accessed, also helped. That is not in itself strictly true,
Re: Tomcat access log reveals hack attempt: HEAD /manager/html HTTP/1.0 404
In what I believe to be related anough to the subject of the original post, I would like to float a proposal, to make life a bit harder for these automated hackers. By personal observation, I note that many such attempts (the large majority in fact) end up requesting URLs which do not exist on properly-configured servers, and thus ultimately result in a 404 Not Found response. It is also the interest of these annoying tools to be able to scan as many IP addresses and ports as possible, within as short a time as possible, in order to locate vulnerable targets faster. But nevertheless, they cannot use too short a timeout for each of these URLs that they request, otherwise they would end up neglecting a lot of juicy targets whenever their own network connection (or the target's) is a bit slow. On the other hand, I would suppose that legitimate well-written applications rarely deliver responses containing links that will, when used, result in 404 responses. So why not insert an optional parameter into Tomcat somewhere, which would have the effect of delaying any 404 Not Found response by a few (configurable) seconds ? I am quite sure that if this was done cleverly, its impact on the server's own load could be minimised, and it would greatly annoy those miscreants, by forcing them to wait n times longer for each unsuccesful attempt. No ? - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Tomcat access log reveals hack attempt: HEAD /manager/html HTTP/1.0 404
How about creating a fake manager application :))) That takes X minutes/seconds to get back a 404 ;)))
Re: Re : Memory leak in Tomcat 6.0.35 ( 64 bit)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Howard, On 4/14/13 9:53 PM, Howard W. Smith, Jr. wrote: I am definitely relying on user HttpSessions, and I do JPA-level caching (statement cache and query results cache). pages are PrimeFaces and primefaces = xhtml, html, jquery, and MyFaces/OpenWebBeans to help with speed/performance. And right now, the app handles on a 'few' simultaneous connections/users that do small and large fetches/inserts from/into relational database. :) You can tune the JPA caching, etc. to meet your environmental needs, etc., so you don't *need* a huge heap. If you find that you need to be able to improve your performance, you might be able to increase your cache size if it in fact improves things. sometimes, i do keep large amount of data in user HttpSession objects, but still being somewhat junior java/jsf developer and listening to you all on tomcat list and other senior java/jsf developers, I want to move some of my logic and caching of data from SessionScoped beans to RequestScoped beans. You might be able to have your cake and eat it, too. There is an interesting class called WeakReference that you can use to interact with the memory manager and garbage-collector. If you have a bunch of stuff cached in the session, as long as you could re-construct the cache given some value (like user_id or whatever), you can make the big, cached stuff in the session into so-called weak-references. If the GC wants to re-claim memory, it can discard weak references and the WeakReference object will then point to null. That allows you to have a nice cache that auto-cleans if you start running low on memory. I've written a Filter and HttpSession wrapper that can do that kind of thing transparently to the application code. I don't actually use it right now -- it was just a proof-of concept -- but it's a quick and dirty way to get caching but also save a safety valve. - -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/ iQIcBAEBCAAGBQJRbDQhAAoJEBzwKT+lPKRY2voP/RejVzXwT9q3Bpq8C85sdmaU rf4l8aSAeHY9iZDuU27dGIPYcM8eD503UFdLxNrLQmsAnIGgecxcybSzTCIaA8Q1 kqtA58KOOkSwjWzSzyLhr7glDELXlB7BW1wiKuclrSE99NLmLQIwt5osvjv6qYxi jPTU0y1LEKs9mXFjCmwpdjxryttMOPL+3NMjYy0PrauwxtWR1uPS3r+1bhkjtbSs srx4aV98bFso7NydTPrbGahOHRnY1s7deNq1AzcaYsKV0ASky5cgagmk9qRyfxMd UBAo4+cxQG2V9ccGO4PR+cuL6JQuLhfxexneFfR+FSbFPCmM9axNBexqi73BL79q 1aOffzSKLc9gS1I7MjXgMwc20K+bDYmnWOsePAJpCIt9Jl3S77AKQYzBWapCXCu0 H+vtVEjvH38fuByNtNTBOonqztw7EFuOAMJWg1vRzWfZyeXSljewdLjw/+jTJYNA iULuGit9BTfIVwT2jaGfVmjebwy47GqaaisK+BF9/gLAGsG9/sSpfnYPOkjGpAZu 1+5nYnGzx8rqlgdPOmxh0MJiJdbLeg7yJxuFnCTe5X7i4wE7jUUkBGmqnWroiYD0 iCxWU81XQMeJDob6WMw2Cori8ZUHt/oBGz3p33ip/NzPihQrlLqqIIx3zYwpM4vt H6hYuvJ+/t8PHKDhHR+K =guqf -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Tomcat access log reveals hack attempt: HEAD /manager/html HTTP/1.0 404
Neven Cvetkovic wrote: How about creating a fake manager application :))) That takes X minutes/seconds to get back a 404 ;))) Just for the sake of the discussion : - a fake manager application would apply to just the /manager webapp, not to other potential hacking targets, no ? (or you would have to map it to any potential hacking URL, which may be inconvenient). Also, you'd have to duplicate this webapp in any configured Host. - the fact that it is a genuine webapp would mean that during the delay before the 404 response, at least one tomcat thread remains blocked executing that application, for each such request. I was thinking more in the direction of off-loading such 404 responses to some specialised lightweight thread, using as little resources as possible. It wouldn't really matter if there is a queue of such responses waiting to happen, as they just delay the eventual response to the (miscreant) client(s). More ideas ? P.S. I'd love to see this as a standard Tomcat feature, because it would mean that within a certain time period, thousands and thousands of Tomcat servers on the Internet would become annoying for these hacking programs. If it was a webapp that everyone has to deploy on individual tomcat servers optionally, it would be much less effective, I think. Of course at the moment I am just fishing here for potential negative side-effects. Provided the idea makes sense however, I believe that I would also post it on the Apache httpd list. If it was adopted there also somehow, that could have quite a global impact. One potential negative side-effect that I can see, is on one of my own programs (or similar ones) : for some customers, I created a URL checker program, which goes through their databases looking for third-party links, and gives them a list of the ones that are not working (so that they can correct their data). Of course if all webservers on the web implemented my idea, then it would take much longer for this genuine utility program to run, because it would experience an extra delay for each incorrect URL (in case the host is correct, but the URL on that server is not). I'm also quite sure that Google won't really like the idea.. - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Tomcat access log reveals hack attempt: HEAD /manager/html HTTP/1.0 404
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Pid, On 4/15/13 6:19 AM, Pid wrote: On 15/04/2013 00:03, Christopher Schultz wrote: Pid, On 4/12/13 1:54 PM, Pïd stèr wrote: On 11 Apr 2013, at 21:36, Christopher Schultz ch...@christopherschultz.net wrote: [...] though I would run Apache httpd and Tomcat on different hosts, so localhost-binding is not possible unless you are doing something like stunnel (which also might be a good idea if you are traversing an untrusted network). Respectfully, I have to disagree. Unless the Apache HTTPD is loaded with IDS that can sniff the inbound traffic, you've not achieved much, and now you have two boxes that have to be maintained, secured patched. HTTPD != firewall. While httpd != firewall, it's traditional to allow external-access to your web server but not your app servers (databases, etc.). That means that external threats can only directly-attack the web server. Respectfully, this is clearly not true if you are just passing traffic to the app server. An attack that compromises the application server in the way described above would still be effective regardless of the presence of HTTPD. The risk I perceive is that users think that simply installing HTTPD somehow improves their security, when it does not. Agreed. Having a physical server (running httpd) between the wild Internet and the application server does improve a certain type of security (not via HTTP -- if I have an SQL injection vulnerability, adding httpd does not help). However, if you break-into my web server but there's nothing else running there (yes, you can sniff traffic, etc. which is very bad) you still haven't broken-into my application server. The 'traditional' approach in these matters needs close scrutiny IMO. People can't afford to rely on received wisdom for security and forget more important basics such as regular patching. I regularly debate this with customers and we usually agree/find a better approach. Obviously, suffering a web server break-in sucks, but at least the attacker then needs to break-into the application server after that. Why would they bother if they can attack the applications directly anyway? Agreed. I was focusing less on application-security and more on environmental-security for this discussion. I think that is why we may not be seeing eye-to-eye. Obviously, a layered-approach to security is critical, and operational security is just one of those layers. If it's a one-box wonder, you've been owned in a one fell swoop. A bit like this one, then. ;) Also, running a heterogeneous environment can thwart attackers who have some kind of zero-day that got them into the web server (e.g. running httpd on Linux). Then they try the app server and surprise! It's NetBSD and they have to stop and find another attack to proceed. This is of course possible, but in practice quite rare. Yup: it costs more because you have to have a wider range of expertise on your ops team. - -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/ iQIcBAEBCAAGBQJRbDafAAoJEBzwKT+lPKRYt3cQALXO+cRSp+K7a+lyy/pAYKX9 l1dFIAmydt7NUvdNN7VmrGCqIB8L3oUx8DFCOcuuVMtlPOyuyyFMykARD0UX9Gkz wF/jQXHYw+BUTIxpxSGX+9IEqVS0PW3+icFTjNEq7DFvi6T9vR7SzEBBo1I0yBxL udbmHXSrWyp+eR8gDcrT8yeTQ0NIO7gXh/MZTbNYoBhaYfnWXbQRdSSLBAh2qb33 U0hFaQ1nXyhF40FgJJ4H6SniITf/QLRVSOxyXye2HCoPxpfK5hogwmd6uWTT/yxt pGuGsRAscn1ay5RJKLQVlJwgD2fwpEbXTWPwaBPAxX0GzmvP5Wyc+taGDVfArYuS cVwb9fyasgW15N44yzmEPrqjTl5iu0GDz88i7dtEcQgtdjVzkqbiHr3h5EpPaBKo Rv010bxXrpESqjrpjvET9dHCQW8WAsxFbiv+T2EC5dKhXR88TZhiIJRvOYIlTxZF tYCxgCUbJ3ssQZw2YKK+smHbOWZpD2jnTW1XPfU1Gc8A5hGfZDgAIaEXPnPVb5NR 0VGiNpzPWjl3zZMFlDJVzKrXnwOFbiI/vpBhysH+6CiHdTgBMDKlkMMP/Bu+0o6/ qUMKRac0L48Di7n3Mf4sAOBD/1+UOV8PndtI7JcZe8D4dAeCp2ILMGT1b+gkDwye WJvLNrAnam+2f/Sj1I07 =jTiG -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Tomcat access log reveals hack attempt: HEAD /manager/html HTTP/1.0 404
On 4/15/2013 10:15 AM, André Warnier wrote: Neven Cvetkovic wrote: How about creating a fake manager application :))) That takes X minutes/seconds to get back a 404 ;))) Just for the sake of the discussion : - a fake manager application would apply to just the /manager webapp, not to other potential hacking targets, no ? (or you would have to map it to any potential hacking URL, which may be inconvenient). Also, you'd have to duplicate this webapp in any configured Host. - the fact that it is a genuine webapp would mean that during the delay before the 404 response, at least one tomcat thread remains blocked executing that application, for each such request. I was thinking more in the direction of off-loading such 404 responses to some specialised lightweight thread, using as little resources as possible. It wouldn't really matter if there is a queue of such responses waiting to happen, as they just delay the eventual response to the (miscreant) client(s). More ideas ? P.S. I'd love to see this as a standard Tomcat feature, because it would mean that within a certain time period, thousands and thousands of Tomcat servers on the Internet would become annoying for these hacking programs. If it was a webapp that everyone has to deploy on individual tomcat servers optionally, it would be much less effective, I think. Of course at the moment I am just fishing here for potential negative side-effects. Provided the idea makes sense however, I believe that I would also post it on the Apache httpd list. If it was adopted there also somehow, that could have quite a global impact. One potential negative side-effect that I can see, is on one of my own programs (or similar ones) : for some customers, I created a URL checker program, which goes through their databases looking for third-party links, and gives them a list of the ones that are not working (so that they can correct their data). Of course if all webservers on the web implemented my idea, then it would take much longer for this genuine utility program to run, because it would experience an extra delay for each incorrect URL (in case the host is correct, but the URL on that server is not). I'm also quite sure that Google won't really like the idea.. Google mod_security honeypot for ideas similar to this. Couple that with a mod_security exec to add IP addresses to firewalls or iptables, and I think you have a real chance at being annoying to many script-driven attacks. The cracking / botnet tools used today are really quite sophisticated. Here's an article touching the edge of what's going on: http://arstechnica.com/security/2013/04/a-beginners-guide-to-building-botnets-with-little-assembly-required/ Fun and games. . . . . just my two cents. /mde/ - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Apache HTTPD + Tomcat restarts
All, I made a simple change to the Apache HTTPD configs - I reduced the number of loaded modules - and then stopped and started Apache. On the QA environment, Tomcat did not need a restart. On the PROD (production) environment, soon after Apache was restarted, the application URLs resolved okay. But a minute later, I received an Internal Server Error from Apache. Hitting Tomcat directly did not work either. It required a Tomcat restart to start receiving the URLs again. I am not sure why the two environments behaved differently. It was not my browser cache, 'cause I reloaded the URL. It was not the loadbalancer RAM Cache as the loadbalancer RAM Cache is disabled. Didn't find anything in the logs. I wanted to know your thoughts. Thanks. -Shanti
Re: Re : Memory leak in Tomcat 6.0.35 ( 64 bit)
On Mon, Apr 15, 2013 at 11:18 AM, Mark Eggers its_toas...@yahoo.com wrote: On 4/15/2013 7:25 AM, David kerber wrote: On 4/15/2013 10:10 AM, Howard W. Smith, Jr. wrote: On Mon, Apr 15, 2013 at 7:40 AM, David kerberdcker...@verizon.net wrote: On 4/14/2013 11:10 PM, Howard W. Smith, Jr. wrote: On Sun, Apr 14, 2013 at 10:52 PM, Mark Thomasma...@apache.org wrote: On 14/04/2013 21:53, Howard W. Smith, Jr. wrote: On Sun, Apr 14, 2013 at 6:51 PM, Christopher Schultz ch...@christopherschultz.net wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Howard, On 4/11/13 10:38 PM, Howard W. Smith, Jr. wrote: On Thu, Apr 4, 2013 at 2:32 PM, Christopher Schultz ch...@christopherschultz.net wrote: Your heap settings should be tailored to your environment and usage scenarios. Interesting. I suppose 'your environment' means memory available, operating system, hardware. Usage scenarios? hmmm... please clarify with a brief example, thanks. :) Here's an example: Let's say that your webapp doesn't use HttpSessions and does no caching. You need to be able to handle 100 simultaneous connections that do small fetches/inserts from/into a relational database. Your pages are fairly simple and don't have any kind of heavyweight app framework taking-up a whole bunch of memory to do simple things. Thanks Chris for the example. This is definitely not my app. I am definitely relying on user HttpSessions, and I do JPA-level caching (statement cache and query results cache). pages are PrimeFaces and primefaces = xhtml, html, jquery, and MyFaces/OpenWebBeans to help with speed/performance. And right now, the app handles on a 'few' simultaneous connections/users that do small and large fetches/inserts from/into relational database. :) Hopefully one day, my app will be support 100+ simultaneous connections/users. For this situation, you can probably get away with a 64MiB heap. If your webapp uses more than 64MiB, there is probably some kind of problem. If you only need a 64MiB heap, then you can probably run on fairly modest hardware: there's no need to lease that 128GiB server your vendor is trying to talk you into. Understood, thanks. I have Xms/Xmx = 1024m, and I rarely see used memory get over 400 or 500m. the production server has 32GB RAM. I'll summarize a number of JavaOne sesisons I've been to on GC and performance (caveat - this was a couple of years ago and GC design has moved on since then). - GC pause time - throughput - small memory footprint You can optimise for any two of the above at the expense of the third. Assuming you opt for min GC pause time and max throughput the question then becomes how much heap do you need? If you look at your steady state heap usage graph (it should be a saw-tooth) then take the heap usage at the bottom of the saw-tooth and multiply it by 5 - that is the heap size you should use for the GC to work optimally. HTH, Mark Interesting, that does help, Mark, thanks. 250 x 5 = 1,250. I guess I was pretty close on target when I set Xms/Xmx = 1024m. Prior to seeing your email/response, I checked the server again, and it was no saw-tooth at all, it was at 250 (bottom), and then saw-tooth graph came into play...minutes later. Make sure you give it enough time for the memory use to stabilize. Will do (and doing that), thanks. :) Depending on your app and usage patterns, it can take up to days for the sawtooth to stabilize and start showing. One of mine takes a couple of hours, and another a few days for that pattern to become visible. I see it stabilize 'in minutes' (after/during usage of the app). Just now (prior to writing this email), I was looking at the app's usage (via monitoring the app's own data/record audit trail page), and then decided to check-on the app to see how it is doing/performing via jvisualvm, and voila, again, I saw no saw-tooth[1]. I saw this, 5 to 15 minutes after a period of inactivity in the app, but before I logged into the app, as I stated above, I checked the app's audit trail (which can definitely be a 'heavy-lifting' database query, depending on work done within the app on selected date, default = current date), and it[1] still showed no activity (or saw-tooth); I assume activity within the app can = definite/obvious saw-tooth graph (which also means, GC is working while app is being used). What I mentioned above is very normal behavior for my app. [1] http://img805.imageshack.us/**img805/8453/**20130415jvisualvm01.pnghttp://img805.imageshack.us/img805/8453/20130415jvisualvm01.png These graphs are only showing ~40 seconds of data. I'll bet if you let the app run for several minutes or hours, you'll see it. Yep, there's no history in that data. Agreed! :) What you can do (probably in a test environment) is the following: 1. Set up monitoring (visualvm, psi-probe,
Re: Apache HTTPD + Tomcat restarts
On 4/15/2013 12:14 PM, Shanti Suresh wrote: All, I made a simple change to the Apache HTTPD configs - I reduced the number of loaded modules - and then stopped and started Apache. On the QA environment, Tomcat did not need a restart. On the PROD (production) environment, soon after Apache was restarted, the application URLs resolved okay. But a minute later, I received an Internal Server Error from Apache. Hitting Tomcat directly did not work either. It required a Tomcat restart to start receiving the URLs again. I am not sure why the two environments behaved differently. It was not my browser cache, 'cause I reloaded the URL. It was not the loadbalancer RAM Cache as the loadbalancer RAM Cache is disabled. Didn't find anything in the logs. I wanted to know your thoughts. Thanks. -Shanti Apache HTTPD modules do not influence how Apache Tomcat runs. So now I have a little better picture of what's running: Browser -- Apache HTTPD -- (multiple) Tomcats I don't have any idea what version of anything you're running. I'm going to guess (again) that you're using mod_jk and a load balancer configuration. However you could be using mod_proxy and mod_proxy_balancer. I don't know. If the 500 Internal Server Error is from Apache HTTPD, then it's an Apache HTTPD configuration issue and belongs on the Apache HTTPD mailing list. Are you running mod_security in production? I've seen some mod_security Internal Server Error issues when posting WAR files through Apache HTTPD / mod_jk / Tomcat. The log file for that should be where Apache HTTPD logs things. If the Internal Server Error comes from Tomcat, then it's most likely your application. You can check the log files in CATALINA_BASE/logs. There should be information in those logs. If you are running mod_security on a front-end Apache HTTPD server and want to quickly check, you could add the following to an Apache HTTPD server virtual host to turn it off (temporarily). IfModule security2_module SecRuleEngine Off /IfModule If that cures your problem, then you should take things up with the mod_security mailing list. Of course, this is all a guess (I'll put your crystal ball back in a second, Pid). More information is needed: Versions of: Apache HTTPD Apache Tomcat Java Operating system and version Method you use to connect Apache HTTPD to Apache Tomcat Text of the Internal Server Error. If you've not configured an error page for the 500 error, then you'll see a stack trace if it's from Tomcat. Without all of this information (at a minimum), the best anyone can do is guess. . . . . just my two cents /mde/ - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Apache HTTPD + Tomcat restarts
Mark Eggers wrote: On 4/15/2013 12:14 PM, Shanti Suresh wrote: All, I made a simple change to the Apache HTTPD configs - I reduced the number of loaded modules - and then stopped and started Apache. On the QA environment, Tomcat did not need a restart. On the PROD (production) environment, soon after Apache was restarted, the application URLs resolved okay. But a minute later, I received an Internal Server Error from Apache. Hitting Tomcat directly did not work either. It required a Tomcat restart to start receiving the URLs again. I am not sure why the two environments behaved differently. It was not my browser cache, 'cause I reloaded the URL. It was not the loadbalancer RAM Cache as the loadbalancer RAM Cache is disabled. Didn't find anything in the logs. I wanted to know your thoughts. Thanks. -Shanti Apache HTTPD modules do not influence how Apache Tomcat runs. So now I have a little better picture of what's running: Browser -- Apache HTTPD -- (multiple) Tomcats I don't have any idea what version of anything you're running. I'm going to guess (again) that you're using mod_jk and a load balancer configuration. However you could be using mod_proxy and mod_proxy_balancer. I don't know. If the 500 Internal Server Error is from Apache HTTPD, then it's an Apache HTTPD configuration issue and belongs on the Apache HTTPD mailing list. Are you running mod_security in production? I've seen some mod_security Internal Server Error issues when posting WAR files through Apache HTTPD / mod_jk / Tomcat. The log file for that should be where Apache HTTPD logs things. If the Internal Server Error comes from Tomcat, then it's most likely your application. You can check the log files in CATALINA_BASE/logs. There should be information in those logs. If you are running mod_security on a front-end Apache HTTPD server and want to quickly check, you could add the following to an Apache HTTPD server virtual host to turn it off (temporarily). IfModule security2_module SecRuleEngine Off /IfModule If that cures your problem, then you should take things up with the mod_security mailing list. Of course, this is all a guess (I'll put your crystal ball back in a second, Pid). More information is needed: Versions of: Apache HTTPD Apache Tomcat Java Operating system and version Method you use to connect Apache HTTPD to Apache Tomcat Text of the Internal Server Error. If you've not configured an error page for the 500 error, then you'll see a stack trace if it's from Tomcat. Without all of this information (at a minimum), the best anyone can do is guess. And you are guessing quite a lot. With the information provided by the OP initially, I was going to ask if Apache httpd and Tomcat were located in the same city and/or connected in any way. Oh, and he also mentioned a loadbalancer cache. Either Pid or Quantum Theory might be of help here. - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Re : Memory leak in Tomcat 6.0.35 ( 64 bit)
On Mon, Apr 15, 2013 at 1:08 PM, Christopher Schultz ch...@christopherschultz.net wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Howard, On 4/14/13 9:53 PM, Howard W. Smith, Jr. wrote: I am definitely relying on user HttpSessions, and I do JPA-level caching (statement cache and query results cache). pages are PrimeFaces and primefaces = xhtml, html, jquery, and MyFaces/OpenWebBeans to help with speed/performance. And right now, the app handles on a 'few' simultaneous connections/users that do small and large fetches/inserts from/into relational database. :) You can tune the JPA caching, etc. to meet your environmental needs, etc., so you don't *need* a huge heap. If you find that you need to be able to improve your performance, you might be able to increase your cache size if it in fact improves things. doing this, and just made some code changes to tap a little more into JPA caching, but one of my endusers just did a user operation on one of the pages, and he sent me a screen capture of the nasty eclipselink error that he experienced. evidently, i need to tweak caching or do not use the cache at that point in the app. :) i explained to him that i did some major changes in the app, related to caching... and i told him that it was for 'performance improvement', and told him the same as Mark just told me, Google is your friend (and told him that 'wiki' keyword in the search is your friend, too). :) sometimes, i do keep large amount of data in user HttpSession objects, but still being somewhat junior java/jsf developer and listening to you all on tomcat list and other senior java/jsf developers, I want to move some of my logic and caching of data from SessionScoped beans to RequestScoped beans. You might be able to have your cake and eat it, too. There is an interesting class called WeakReference that you can use to interact with the memory manager and garbage-collector. If you have a bunch of stuff cached in the session, as long as you could re-construct the cache given some value (like user_id or whatever), you can make the big, cached stuff in the session into so-called weak-references. If the GC wants to re-claim memory, it can discard weak references and the WeakReference object will then point to null. That allows you to have a nice cache that auto-cleans if you start running low on memory. very interesting. since i'm using gson to accept some JSON-wrapped data into my app from our public website (static pages and formmail, only, for now, until i integrate it with the web app i developed for personnel, only, for now), i didn't like the warning/msg when tomcat/tomee 'stops'...says that weak reference could not be deleted or something like that (sorry, i forgot exactly what it said). Anyway, i followed some issue in gson's issue tracker (on code.google.com), and someone offered some code to delete gson from weak reference, so i decided to add that to my app, when i shutdown app. so, i do know that the weak reference class is available. really have not 'used' it yet, though. :) i have some things in mind what I want to do with that large session scoped data. I am considering caching it at application level and all users have ability to update that huge List and extract data. I was thinking of using @Singleton Lock(READ) to control access. it takes no time at all to search the List for the information that it needs, and it takes no time at all to re-populate the List. Since we discuss GC a lot on this list, i wonder if you all recommend to set the 'list' to null, first, and then List ... = new ArrayList(newList), or new ArrayList(newList) is sufficient for good GC. I've written a Filter and HttpSession wrapper that can do that kind of thing transparently to the application code. I don't actually use it right now -- it was just a proof-of concept -- but it's a quick and dirty way to get caching but also save a safety valve. that's nice proof of concept! I guess i've heard so much bad about people not cleaning up threadlocals, that I try to avoid usage of threadlocal, but it's interesting, so much talk on this list about threadlocals, but they threadlocals seem to be used by many implementations/software out there. Not naming any names. :) - -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/ iQIcBAEBCAAGBQJRbDQhAAoJEBzwKT+lPKRY2voP/RejVzXwT9q3Bpq8C85sdmaU rf4l8aSAeHY9iZDuU27dGIPYcM8eD503UFdLxNrLQmsAnIGgecxcybSzTCIaA8Q1 kqtA58KOOkSwjWzSzyLhr7glDELXlB7BW1wiKuclrSE99NLmLQIwt5osvjv6qYxi jPTU0y1LEKs9mXFjCmwpdjxryttMOPL+3NMjYy0PrauwxtWR1uPS3r+1bhkjtbSs srx4aV98bFso7NydTPrbGahOHRnY1s7deNq1AzcaYsKV0ASky5cgagmk9qRyfxMd UBAo4+cxQG2V9ccGO4PR+cuL6JQuLhfxexneFfR+FSbFPCmM9axNBexqi73BL79q 1aOffzSKLc9gS1I7MjXgMwc20K+bDYmnWOsePAJpCIt9Jl3S77AKQYzBWapCXCu0
Re: Apache HTTPD + Tomcat restarts
Hi all, Apologies :-) I was expecting a simple yes/no response. On Mon, Apr 15, 2013 at 4:01 PM, André Warnier a...@ice-sa.com wrote: Mark Eggers wrote: Apache HTTPD modules do not influence how Apache Tomcat runs. That's what I thought. If that cures your problem, then you should take things up with the mod_security mailing list. Thank you! I am not running mod_security. Versions of: Apache HTTPD Server version: Apache/2.2.3 Apache Tomcat apache-tomcat-7.0.23 Java jre-1.6.0-sun.x86_64 Operating system and version RedHat Linux 2.6.18-348.2.1.el5 Method you use to connect Apache HTTPD to Apache Tomcat mod_proxy + mod_proxy_http Text of the Internal Server Error. If you've not configured an error page for the 500 error, then you'll see a stack trace if it's from Tomcat. Don't have the Internal Server error's exact text. There was no stack trace from Tomcat. It was simply an Internal Server 500 error text on the Apache side. I have not configured an error page. Gosh! I don't recollect anything on the Tomcat direct-hit either. Otherwise, I would be a happy camper. And you are guessing quite a lot. With the information provided by the OP initially, I was going to ask if Apache httpd and Tomcat were located in the same city and/or connected in any way. Oh, and he also mentioned a loadbalancer cache. Either Pid or Quantum Theory might be of help here. My apologies. Here's all I have from Apache's error log. Several entries looking like so starting at: -- [Thu Apr 11 21:24:14 2013] [error] [client nnn.nnn.nnn.nnn] (70007)The timeout specified has expired: proxy: error reading status line from remote server servername.do.ma.in [Thu Apr 11 21:24:14 2013] [error] [client nnn.nnn.nnn.nnn] proxy: Error reading from remote server returned by /web-app/url1/ [Thu Apr 11 21:24:55 2013] [error] [client nnn.nnn.nnn.nnn] proxy: Error reading from remote server returned by /web-app/url2, referer: http://example.com/people/employees/regularemployee [Thu Apr 11 21:24:55 2013] [error] [client nnn.nnn.nnn.nnn] (70007)The timeout specified has expired: proxy: error reading status line from remote server servername.do.ma.in, referer: https://www.google.com/ - Apache and Tomcat are in the same city, and in the same data-center. And Apr 11 21:05 is when I restarted Apache after removing several unused modules - hard stop and start. The way I restarted Apache is: sudo /usr/sbin/service httpd stop sudo /usr/bin/servive httpd start Thanks. -Shanti
Re: path attribute from Context.xml is not working
Chuck, thank you for your help. Asterisks where from bolding as Neven wrote. When Context is defined in server.xml it's path attribute works fine. Actually I have read, but not understood doc. I concentrated on second part of sentace saying unless either the docBase is not located under the Hosthttp://tomcat.apache.org/tomcat-7.0-doc/config/host.html's appBase which was true in my case, but somehow I missed unfulfilled precondition. Thx once again, regards , Jakub On Mon, Apr 15, 2013 at 1:28 AM, Caldarale, Charles R chuck.caldar...@unisys.com wrote: From: Jakub 1983 [mailto:jjaku...@gmail.com] Subject: path attribute from Context.xml is not working in file *someConf*.xml under directory C:\test\catalina_base\conf\Catalina\localhost I define path: Context *docBase*=C:\externaltests\test1\exploded *path*=/someConf*Path* / (For curiosity's sake, what are those silly asterisks doing in your config?) You appear to have not read the description of the path attribute in the Context doc: This attribute must only be used when statically defining a Context in server.xml. how can I make tomcat to use path attribute form Context element ? You can't, and don't try. Change the name of the .xml file to the desired path. - 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: Apache HTTPD + Tomcat restarts
On Mon, Apr 15, 2013 at 5:02 PM, Shanti Suresh sha...@umich.edu wrote: And Apr 11 21:05 is when I restarted Apache after removing several unused modules - hard stop and start. The way I restarted Apache is: sudo /usr/sbin/service httpd stop sudo /usr/bin/servive httpd start Typo. Should be read as: sudo /sbin/service httpd stop sudo /sbin/service httpd start Thanks! -Shanti
RE: Re : Memory leak in Tomcat 6.0.35 ( 64 bit)
-Original Message- From: Christopher Schultz [mailto:ch...@christopherschultz.net] Sent: Sunday, April 14, 2013 5:52 PM To: Tomcat Users List Subject: Re: Re : Memory leak in Tomcat 6.0.35 ( 64 bit) I've had people tell me that I should run with the biggest heap I can afford meaning both financially - 'cause you have to buy a bunch of memory - and reasonably within the constraints of the OS (it's not reasonably to run a 9.9GiB heap with 10GiB of physical RAM, for instance). The reasoning is twofold: 1. If you have leaks, they will take a lot more time to blow up. (Obviously, this is the opposite of my recommendation, but it's worth mentioning as it's a sound argument. I just disagree with the conclusion). If you watch the heap-usage profile over time, you can see it going up and up and instead of getting an OOME, you can predict when it will happen and bounce the server at your convenience. Chris - My back-argument to this reasoning is this: It's fine for the production side in order to maximize uptime while you investigate the cause of the leaks. Then I recommend your suggestion for the Dev/Test environment to isolate the cause(s). Once fixed, bring the production side back to something resembling normality. Jeff - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Apache HTTPD + Tomcat restarts
Shanti Suresh wrote: Hi all, Apologies :-) I was expecting a simple yes/no response. Well, you wrote that you wanted to know our thoughts. Yes or No would not have been an appropriate response to that, so we elaborated a bit. ;-) On Mon, Apr 15, 2013 at 4:01 PM, André Warnier a...@ice-sa.com wrote: Mark Eggers wrote: Apache HTTPD modules do not influence how Apache Tomcat runs. That's what I thought. If that cures your problem, then you should take things up with the mod_security mailing list. Thank you! I am not running mod_security. Versions of: Apache HTTPD Server version: Apache/2.2.3 Apache Tomcat apache-tomcat-7.0.23 Java jre-1.6.0-sun.x86_64 Operating system and version RedHat Linux 2.6.18-348.2.1.el5 Method you use to connect Apache HTTPD to Apache Tomcat mod_proxy + mod_proxy_http Text of the Internal Server Error. If you've not configured an error page for the 500 error, then you'll see a stack trace if it's from Tomcat. Don't have the Internal Server error's exact text. There was no stack trace from Tomcat. It was simply an Internal Server 500 error text on the Apache side. I have not configured an error page. Gosh! I don't recollect anything on the Tomcat direct-hit either. Otherwise, I would be a happy camper. And you are guessing quite a lot. With the information provided by the OP initially, I was going to ask if Apache httpd and Tomcat were located in the same city and/or connected in any way. Oh, and he also mentioned a loadbalancer cache. Either Pid or Quantum Theory might be of help here. My apologies. Here's all I have from Apache's error log. Several entries looking like so starting at: -- [Thu Apr 11 21:24:14 2013] [error] [client nnn.nnn.nnn.nnn] (70007)The timeout specified has expired: proxy: error reading status line from remote server servername.do.ma.in [Thu Apr 11 21:24:14 2013] [error] [client nnn.nnn.nnn.nnn] proxy: Error reading from remote server returned by /web-app/url1/ [Thu Apr 11 21:24:55 2013] [error] [client nnn.nnn.nnn.nnn] proxy: Error reading from remote server returned by /web-app/url2, referer: http://example.com/people/employees/regularemployee [Thu Apr 11 21:24:55 2013] [error] [client nnn.nnn.nnn.nnn] (70007)The timeout specified has expired: proxy: error reading status line from remote server servername.do.ma.in, referer: https://www.google.com/ - Apache and Tomcat are in the same city, and in the same data-center. And Apr 11 21:05 is when I restarted Apache after removing several unused modules - hard stop and start. The way I restarted Apache is: sudo /usr/sbin/service httpd stop sudo /usr/bin/servive httpd start So you wrote that you restarted Apache at 21:05, and that about a minute later you had some Server Errors. The log messages above are dated of 21:24. That is 20 minutes after the restart, not really 1 minute. If I have to express a thought based on that conflicting information, then I would guess that the errors are probably not related to the restart of Apache per se. It may just have been a coincidence. Although using the term coincidence for events that happen at a 20-minute interval on a production server seems a bit of a stretch. The (edited) error log shown above just tells us that at 21:24:14, Apache+mod_proxy determined that there was a timeout following an earlier request to Tomcat. In other words, Apache proxied a request to Tomcat, and Tomcat did not respond in time, so mod_proxy gave up waiting and aborted the request with an error. And then again 40 seconds later at 21:24:55, same issue. Now why at that time Tomcat did not respond in time (or at all), is a mystery as well for us as for you. There is nothing there that would tell us when the request which failed was actually started. We just see when it failed. Maybe by looking at the same time at the Apache access log and at this error log, you can determine which requests failed, and figure out if there is some logical reason at the Tomcat level. Maybe these requests were just so that Tomcat really took too long to answer, and mod_proxy lost patience... In any case, there is nothing there that specifically links the Apache restart, with the errors that happened later. If Tomcat tried to send a response later (after Apache httpd timed-out), then there should probably be an error message also in the Tomcat logs, since it would try to write back a response onto a connection that did not exist anymore. Have you checked the Tomcat logs ? (which may be in /var/log/daemon, depending on the script which starts Tomcat). - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Tomcat 5.0.28 documentation
Thanks for your replies. Would like to refer only documentation for 5.0.28. Any other possibility? Regards, Eashwar On Mon, Apr 15, 2013 at 7:56 PM, Mark Eggers its_toas...@yahoo.com wrote: On 4/15/2013 5:03 AM, Ognjen Blagojevic wrote: M Eashwar, On 15.4.2013 13:25, M Eashwar wrote: I am searching for Tomcat 5.0.28 documentation in old mail archives and searching in web. But still I am not finding that. The reason to find this old documentation is, our application developed long back and its working in Tomcat 5.0.28 only. Tomcat 5.x is unsupported, that is why you will have a hard time finding any documentation for that version. That is for a reason -- Tomcat 5.x is considered outdated and unsafe. Instead of digging old documentation, why don't you consider upgrade to latest Tomcat 7 version (7.0.39 at the moment)? It shouldn't be too hard to do it, especially with support from users on this mailing list. -Ognjen Agreed, far far better to upgrade. However if you must have a copy of Tomcat 5.0.28 (for historical purposes?), you could pull down the original from: http://archive.apache.org/**dist/tomcat/http://archive.apache.org/dist/tomcat/ As Ognjen has pointed out, the likelihood of mailing list support for that version is pretty slim. . . . . just my two cents. /mde/ --**--**- To unsubscribe, e-mail: users-unsubscribe@tomcat.**apache.orgusers-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
ParNew promotion failed in verbose GC logs
Hi Team, Recently I am seeing concurrent mode failure errors in my Verbose GC logs. For the same I have set NewSize to 512MB, still I am seeing concurrent mode failure in the Verbose GC logs 62230.611: [ParNew (promotion failed) Desired survivor size 32768 bytes, new threshold 0 (max 0) : 28481K-28481K(28608K), 0.0483728 secs]62230.659: [CMS (concurrent mode failure) Also Garbage collection is causing some large pauses. The largest pause was 121239 ms. : 1255376K-215461K(2068480K), 121.1880176 secs] 1283830K-215461K(2097088K)Heap after gc invocations=12320: par new generation total 28608K, used 0K [0x6880, 0x6a40, 0x6a40) eden space 28544K, 0% used [0x6880, 0x6880, 0x6a3e) from space 64K, 0% used [0x6a3e, 0x6a3e, 0x6a3f) to space 64K, 0% used [0x6a3f, 0x6a3f, 0x6a40) concurrent mark-sweep generation total 2068480K, used 215461K [0x6a40, 0xe880, 0xe880) concurrent-mark-sweep perm gen total 88496K, used 55091K [0xe880, 0xede6c000, 0xf880) } , 121.2390524 secs] Following is my JVM argument -server -verbose:gc -Xmx2048m -Xms2048m -XX:NewSize=512m -XX:MaxNewSize=512m -XX:MaxPermSize=256M -XX:+UseConcMarkSweepGC -XX:+UseParNewGC -XX:+CMSParallelRemarkEnabled -Dsun.rmi.dgc.client.gcInterval=360 -Dsun.rmi.dgc.server.gcInterval=360 -XX:+DisableExplicitGC -XX:+HeapDumpOnOutOfMemoryError -XX:+HeapDumpOnCtrlBreak -XX:+PrintGCTimeStamps -XX:+PrintHeapAtGC -XX:+PrintClassHistogram -XX:+PrintGCDetails -XX:+PrintTenuringDistribution Tomcat Version 6.0.36 JDK Version Sun HotSpot 1.5.0.22 CPU Number of Physical processor 1 Number of Virtual processor 7 RAM 6144MB OS SunOS 5.10 Generic_147440-09 sun4v sparc sun4v Do you have any idea how to tune it further? Regards, Vidyadhar
