Re: Heap size rule for Tomcat 5.5
On 5 February 2010 18:05, evebill8 evebi...@hotmail.com wrote: Cool! I just want to confirm if the rule is right. My IT guy also does not believe it. It wasn't a bad rule of thumb as a place from which to start tuning when typical server memory sizes were 0.5G to 2G - it reserved sort-of enough RAM for the OS and the non-heap parts of Java and sort-of enough RAM for the web application, though as you can imagine that varied quite a lot. But it could never really be said to be optimal, and ideally you'd always measure and tune. These days, there's so much more RAM in most servers that tuning becomes more relevant if the load's high. If your application is very heavy on disk reads, for example, you might do better to reduce its heap size in order to give the OS more space to cache disk pages. By contrast, I have one *very* heavy compute application (not directly a web app) that likes all the RAM it can get as heap memory to cache intermediate results in case they can be re-used. - Peter
More than 20 users not able to access the application...
How to configure tomcat to use more users concurrently? I'm using Apache2.2 as front end server Tomcat 6 as Back end server. My application is not supporting more 20 users. I'm not able to figure out the problem.. Can you please tell me the Apache Tomcat configuration for more users. Thanks in Advance. -- View this message in context: http://old.nabble.com/More-than-20-users-not-able-to-access-the-application...-tp27478718p27478718.html Sent from the Tomcat - User mailing list archive at Nabble.com.
Re: [Fwd: Re: Parameters disappear from PUTs]
On 06/02/2010 02:27, c...@munat.com wrote: Are you serious? I don't generate request headers. The browser does. And they do so identically whether the HTTP method is PUT or POST and whether it's an XMLHttpRequest or not. And I suspect that they've been doing so pretty much since Marc Andreesen was still in Champaign-Urbana and Mosaic was still an unrealized dream. I'm certain you're not suggesting that browsers be forced to insert a name before the parameter string in every POST request. Tomcat would instantly cease to be a viable option for pretty much everyone. So why are you harping on PUT? In fact, what is it with this list? Is this the PUT Haters Club? Mainly, it is your attitude. Given you are speaking to a community that provides assistance to other members of the community for free, a less argumentative tone would go a long way to help. Why do I have to defend my decision to use PUT requests? When one of the possible solutions is a work-around and that work-around may involve using a method other than PUT then I think it is fair for folks to question the absolute need to use PUT. Why do I have to keep explaining an RFC that should be near and dear to the hearts of anyone who works with web servers? Perhaps if you were using the correct terminology (entity body rather than entity headers) folks here would find it easier to understand you. Hassan was pointing out the correct way to use entity headers. You are trying to use an entity body. What does *any* of this have to do with a simple post to the list explaining that parameters passed with a PUT request seem to be stripped out by Tomcat (though not by Jetty), and asking if this was a bug or intended behavior? I'll address that by replying to your other post that appears to have identified the root cause. Mark - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: More than 20 users not able to access the application...
On 06/02/2010 11:03, Munirathinavel wrote: How to configure tomcat to use more users concurrently? I'm using Apache2.2 as front end server Tomcat 6 as Back end server. My application is not supporting more 20 users. I'm not able to figure out the problem.. Can you please tell me the Apache Tomcat configuration for more users. Thanks in Advance. The spacing you used makes it hard to read. Tomcat can support many concurrent users. Your application probably can't. Seeing as you didn't supply any other information though, it is impossible to provide you with any advice. Exact OS, JVM Tomcat versions to start with, total RAM, JVM memory settings, then some idea of how you know 20 users is your limit. Perhaps log data or meaningful descriptions of the real problem. p - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Parameters disappear from PUTs
On 06/02/2010 03:02, c...@munat.com wrote: I believe that via a post on another list I have discovered the source of the trouble: According to the servlet specification... The following are the conditions that must be met before post form data will be populated to the parameter set: 1. The request is an HTTP or HTTPS request. 2. The HTTP method is POST. 3. The content type is application/x-www-form-urlencoded. 4. The servlet has made an initial call of any of the getParameter family of methods on the request object. So the failure is not Tomcat's, but the Servlet Spec's. There is no reason for this to be limited to POST -- both POST and PUT send entities to the server. I can only presume that this is a feature of Tomcat, ergo I won't bother with a bug report. I have just re-read section 9.6 of RFC2616. My understanding of PUT was (and still is) that the entity body provided is used to create/replace the entity at the provided URI. This is how Tomcat handles PUT requests (it enabled) in the DefaultServlet. My understanding of your PUT request is that the entity body is a series of parameters that are used to create an entity that is then made available at the provided URI. That doesn't match exactly with what I expect having read RFC2616. There is some wiggle room in the specification. SRV.3.1.1 states that: quote The following are the conditions that must be met before post form data will be populated to the parameter set: ... /quote A strict reading of SRV.3.1.1 only refers to how to handle POST data. It makes no reference to PUT data. Therefore, it would not (in my view) be a breach of the spec to treat application/x-www-form-urlencoded PUT requests in the same way as application/x-www-form-urlencoded POST requests. This should probably be optional since this is a grey area. I would be in favour of an enhancement request for Tomcat 7 that implemented such a feature. Mark - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Heap size rule for Tomcat 5.5
Got it! My app is very read intensive so I try to cache lots of objects into the RAM. Therefore, I like to allocate more RAM to the heap since RAM is cheap now. Thanks for your advise! Billy Peter Crowther wrote: On 5 February 2010 18:05, evebill8 evebi...@hotmail.com wrote: Cool! I just want to confirm if the rule is right. My IT guy also does not believe it. It wasn't a bad rule of thumb as a place from which to start tuning when typical server memory sizes were 0.5G to 2G - it reserved sort-of enough RAM for the OS and the non-heap parts of Java and sort-of enough RAM for the web application, though as you can imagine that varied quite a lot. But it could never really be said to be optimal, and ideally you'd always measure and tune. These days, there's so much more RAM in most servers that tuning becomes more relevant if the load's high. If your application is very heavy on disk reads, for example, you might do better to reduce its heap size in order to give the OS more space to cache disk pages. By contrast, I have one *very* heavy compute application (not directly a web app) that likes all the RAM it can get as heap memory to cache intermediate results in case they can be re-used. - Peter -- View this message in context: http://old.nabble.com/Heap-size-rule-for-Tomcat-5.5-tp27463924p27481740.html Sent from the Tomcat - User mailing list archive at Nabble.com. - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
RE: How can I tell if Tomcat is shutting down
Got it, thanks for the pointer! Billy n828cl wrote: From: evebill8 [mailto:evebi...@hotmail.com] Subject: How can I tell if Tomcat is shutting down I want to run some clean up routines before the Tomcat is shutting down. Read section SRV.10 of the servlet spec and the servlet API doc to learn how to use ServletContextListener classes. - 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 -- View this message in context: http://old.nabble.com/How-can-I-tell-if-Tomcat-is-shutting-down-tp27463868p27481759.html Sent from the Tomcat - User mailing list archive at Nabble.com. - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Tomcat dies suddenly
Carl, Here's what I have on my system, you'll obviously need to adjust for your setup, especially the httpd part as I don't believe you're using it: #db-style timestamp STAMP=`date +%F' '%T`; # count the number of httpd child processes AP_COUNT=`ps auxf | grep -c httpd`; # count the number of Tomcat threads. # NOTE: this assumes that the only program that is using java is Tomcat TC_COUNT=`ps auxHS | grep -c bin/java`; # pipe the output of free into grep seaching for the second line MEM_CHECK=`free -m | grep buffers/`; #use a tab delimiter to simplify importing results into a spreadsheet or db TAB=`echo -e '\t'`; MESSAGE=$STAMP$TAB--$TAB$AP_COUNT$TAB$TC_COUNT$TAB$MEM_CHECK$TAB[httpd,tomcat,memory]; echo $MESSAGE; hope you find it helpful On Fri, Feb 5, 2010 at 10:57 PM, chadwickbailey71 chadwickbaile...@yahoo.com wrote: There is no hardware restrictions in 64-bit mode. use 64-bit Linux, this will fix the problem - Learn an http://automatedsocialnetworking.com/ Automated Social Marketing technique WITHOUT Spending More than 5 Minutes Per Month at your Computer :working: -- View this message in context: http://old.nabble.com/Tomcat-dies-suddenly-tp27377457p27476911.html Sent from the Tomcat - User mailing list archive at Nabble.com. - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Tomcat 6 and Apache 2 - using Tomcat 6 with virtual hosts
Hi there everyone. Firstly, i hope this is the correct list to post to. I have been using Tomcat 6 with Apache2 on Debian Lenny for the purposes of hosting multiple Railo websites on the same server. My question is related to virtual hosting and Tomcat 6. I need to be able to create new virtualhosts, and for them to use Tomcat, however from my recent searches Tomcat needs a hard restart in order for it to work. This would impact on all other websites on the same server. So, I would prefer to reload rather than restart. Can anyone know if this is do-able/possible, and if so, could you please suggest the correct way to set this up, or recommend modules that can be implimented or configs that do this. Many thanks in advance Sam - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
RE: Tomcat 6 and Apache 2 - using Tomcat 6 with virtual hosts
From: Sam Anderson [mailto:sam...@gmail.com] Subject: Tomcat 6 and Apache 2 - using Tomcat 6 with virtual hosts Tomcat needs a hard restart in order for it to work. Nope. You can add and remove virtual hosts on the fly with the host-manager app that comes with Tomcat. Unfortunately, there's very little documentation for it, so look at the web.xml file for and experiment a bit. Note that the changes are not persisted, so you'll need to update server.xml separately, or reapply the host-manager commands on each Tomcat restart. - 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: Tomcat dies suddenly
--- On Fri, 2/5/10, Carl c...@etrak-plus.com wrote: Carl, 1. The application runs fine on an older system. Do we have the glibc and kernel versions for all systems? The old system: P4. 1GB memory, 1.3GB swap. Uses swap on a regular basis. kernel is 2.4.25. Java is 1.5.0_01-b08. Tomcat is 5.5.23. Glibc is version 2.3..1. New systems: Server A (Dell T110) is a Xeon 3440, sever B (Dell T105) is an AMD. A has 4GB memory and 19GB swap which is never used. B has 6GB memory and 10GB swap which is never used. A and B both use kernel version 2.6.29.6, Java 1.6.0_18-b07 and Tomcat 6.0.24.. Glibc version is 4.3.3 for both A and B. A couple of observations here: Both the old new kernels end in odd numbers. From memory, I thought the odd kernel numbers were experimental, while the even numbers were production or mainline. I don't remember when this numbering system took place, but certainly by the time the 2.6 kernels were released. From kernel.org, I didn't see a 2.6.29 release marked as stable. The thread implementation has changed between the 2.4 and 2.6 kernels. You can see the thread implementation change by running: getconf GNU_LIBPTHREAD_VERSION I'd be interested in knowing the result of that and getconf GNU_LIBC_VERSION on both systems, since I don't recognize 4.3.3 as a glibc version (latest stable is 2.11.1, so I'm assuming 2.4.3.3?). glibc has some thread bugs that were fixed, but not until 2.8 or 2.9. There was also a persistent bug for 32-bit systems that bites Java applications (not your concern since you're running 64-bit) that wasn't fixed until 2.10.1. So in short, I'm guessing this may be a glibc NPTL issue. There are some observations that don't match, in that you're using Java 6 (most problems are reported with Java 1.4 and Java 5), and that you've used OpenSuSE (kernel, glibc version?) with the same Tomcat failure. However: For some of the earlier 2.6 kernels, you could get around NPTL problems by setting this environment variable: export LD_ASSUME_KERNEL=2.4.1 which forces the use of the old linuxthreads model. I don't know if that option is available with the 2.6 kernel that you are using. Another work-around has been posted on the Java bugs forum, albeit for a different threading problem and Java 5: -XX:ParallelGCThreads=1 sets GC to single threads. It's not fixed in the Java bugs database, because later versions of RedHat Linux don't exhibit the SIGSEGV problem. Some people report that single-threading GC solves their problems, while other people report that it doesn't. Some things to try I guess: 1. export LD_ASSUME_KERNEL=2.4.1 (maybe in startup.sh?) if your kernel supports this.. 2. set -XX:ParallelGCThreads=1 in catalina.sh (JAVA_OPTS). This is an experimental switch, not documented here: http://java.sun.com/javase/technologies/hotspot/vmoptions.jsp, but documented here: http://java.sun.com/javase/technologies/hotspot/gc/gc_tuning_6.html 3. Move to an even-numbered kernel with a glibc of 2.10.1 or better. 2.10 might be OK for your environment since the bug fixed in 2.10.1 causes problems for 32-bit systems only. 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: [Fwd: Re: Parameters disappear from PUTs]
In fact, what is it with this list? Is this the PUT Haters Club? Mainly, it is your attitude. Given you are speaking to a community that provides assistance to other members of the community for free, a less argumentative tone would go a long way to help. Ah. I think I see where the problem lies. You think I came here to get something from you, and so you feel justified in making me jump through hoops to get it. But you have it backwards. I already had a workaround when I came to the list. And I'm pretty sure I'm going to abandon Tomcat anyway in favor of Jetty, or maybe something bigger. I posted to this list to help you. I was letting you know about a potential problem with Tomcat, and offering to help track down whether it was actually Tomcat that was causing that behavior or not. It seems counterproductive to me to attack people who come to help, but maybe that's just me. If I seem argumentative to you, consider that I've put in several hours on this trying to help and provide answers to people -- even when the questions are not germane. I've even backed everything up with evidence. And what I've gotten for my troubles is, frankly, nothing but grief. I am no further ahead than I was before I contacted the list, and I've spent time that I really can't afford to spend. Why do I have to defend my decision to use PUT requests? When one of the possible solutions is a work-around and that work-around may involve using a method other than PUT then I think it is fair for folks to question the absolute need to use PUT. Workarounds are only solutions to people who care only for immediate relief, even if it costs them dearly down the road. A true solution doesn't require a workaround -- it fixes the problem. If you accept workarounds, then it won't be long before you find your code base an unmaintainable mess. I have a workaround. What I'm looking for is a solution, and using a POST for what should be a PUT is not a solution. At best, it's a hack. Why do I have to keep explaining an RFC that should be near and dear to the hearts of anyone who works with web servers? Perhaps if you were using the correct terminology (entity body rather than entity headers) folks here would find it easier to understand you. Hassan was pointing out the correct way to use entity headers. You are trying to use an entity body. If this was really Hassan's intent, then it might have been clearer if he said, I think you are confusing the entity-body with the entity-headers. The paramaters that are being passed are actually the entity-body. I could live with that interpretation, although if you showed the parameters in the HTTP headers to virtually anyone I know, he or she would say those are headers. So if you are right, it is actually at the expense of clear communication, rather than the reverse. But this brings up a good question. I used a Request Dumper Valve (at the suggestion of another person on this list) to check what Tomcat was getting. Although the parameters were definitely passed with the request, they were not present in the dump. The dump showed all the headers. Is the message body not included in the dump? If so, maybe that's where the parameters went. That would be an actual solution, and, in fact, it is where I believe RFC 2616 expects them to be. But note that the parameters are passed in *exactly* the same way in a POST and a PUT. When POSTed, there they are in the Dumper output. When PUTted, there they are not. If the RDV only dumps HTTP headers, and it dumps the parameters in a POST, then they are headers and should be in the PUT. If they are message body in the PUT, then so should they be in the POST, hence they should not be in the dump. Something is not consistent here. What does *any* of this have to do with a simple post to the list explaining that parameters passed with a PUT request seem to be stripped out by Tomcat (though not by Jetty), and asking if this was a bug or intended behavior? I'll address that by replying to your other post that appears to have identified the root cause. Mark - 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 dies suddenly
From: Mark Eggers [mailto:its_toas...@yahoo.com] Subject: Re: Tomcat dies suddenly Both the old new kernels end in odd numbers. From memory, I thought the odd kernel numbers were experimental, while the even numbers were production or mainline. That rule applied to the second field, not the third: 2.1.x, 2.3.x, 2.5.x were experimental and never actually released. However, I believe that rule has been abandoned for 2.6 and beyond. - 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: Parameters disappear from PUTs
I have just re-read section 9.6 of RFC2616. My understanding of PUT was (and still is) that the entity body provided is used to create/replace the entity at the provided URI. This is how Tomcat handles PUT requests (it enabled) in the DefaultServlet. I agree that this is the intent of the RFC. But whether the entity is passed in the headers or in the body is really irrelevant. I see nothing in the RFC to say that the entity *cannot* be passed via the header. As I mentioned in my other email, the parameters are sent by the browser identically for POSTs and PUTs. Nothing in the RFC leads me to believe that it intends for POST entities to travel in the header, so this is probably just a convention established by the browsers. But again, nothing in the RFC leads me to believe that this behavior is prohibited. And even if it is, that's a moot point. Just getting browsers to do PUTs is a real trick (I use AJAX). Tomcat is either going to permit the context to get at those parameters, or it isn't. My understanding of your PUT request is that the entity body is a series of parameters that are used to create an entity that is then made available at the provided URI. That doesn't match exactly with what I expect having read RFC2616. It matters not at all what the entity is that is to be stored, or how it is stored. All that matters is that the server stores it at the specified URI in such a way that it is recoverable via a GET. I PUT; I GET. The entity itself could be a JPEG, an MP3 file, a binary program, an anonymous function, a properties list, a text file, HTML, a style sheet, or plain gibberish -- as long as it gets associated with that URI and comes back the same as it went in (barring other PUTs or DELETEs). How does your understanding differ from this? Example: I could do a PUT of an XML file containing Hamlet to: http://mysite.com/plays/Hamlet Then I could retrieve a part of that play via: http://mysite.com/plays/Hamlet/scenes/I I might then correct some problems, and do a PUT of that scene back to the above URI. Later, I might to a GET to http://mysite.com/plays/Hamlet and get back the whole play with the revised Scene I. The entity is a black box. It may contain sub-entities, each of which is its own black box. HTTP should not care. I PUT and entity, I GET an entity. It's actually very simple There is some wiggle room in the specification. SRV.3.1.1 states that: quote The following are the conditions that must be met before post form data will be populated to the parameter set: ... /quote A strict reading of SRV.3.1.1 only refers to how to handle POST data. It makes no reference to PUT data. Therefore, it would not (in my view) be a breach of the spec to treat application/x-www-form-urlencoded PUT requests in the same way as application/x-www-form-urlencoded POST requests. This should probably be optional since this is a grey area. I would be in favour of an enhancement request for Tomcat 7 that implemented such a feature. Yes, I noted that same thing: these are conditions that must be met before *post* form data will be populated to the parameter set. I believe that the authors weren't even thinking of PUTs at the time (it was 1999, right?), so I don't think this was meant to apply to PUTs, and I think the standard doesn't really address them. The folks at Jetty seem to agree, since AFAICT, Jetty passes the parameters along. But getting the Tomcat folks to change this is probably an uphill battle, and I can just switch to Jetty. I think it would be a very good idea for Tomcat to do it, though, so if someone here has that kind of pull, by all means... And that's all the time I have for this. Good luck with it, and thanks for your replies. Chas. - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
