RE: FW: problem w/ ajp13 - if Tomcat is shutdown
BTW we should redirect this to the tomcat-users list as I don't think its a development issue. I don't see anything wrong, and the only drastic difference from my previous setup was that I had used the default 8007 and 8009. Now This is purely a guess, but I seem to remember reading that ports 1 were special somehow and required root access for some functions. What I would suggest is put those to the default, see if they work, then (I'm assuming you had a reason for ding this) find an acceptable port between 8000-. If that doesn't work then we have a couple more "generic" possiblities (such as running out of file handles which is very common with tomcat on solaris). I wish I still had access to a solaris box to try this.. The only other difference was that I was using Jdk 1.3 (Sun). Which I'd recommend for server side stuff unless you have a compelling reason not to. Its more stable, has less glitches and is faster. Jdk 1.2.x was suns "wowee" and jdk 1.3.x is a performance and stability release (IMHO).. If you haven't tweaked your file handles at any point then there is a good chance that is in the way, unfortunately I do not remember what the strings were to fix this, but I'm sure their documented somewhere (and they're not intuitive).. Hope this helps some. -Andy -Original Message- From: Shinta Tjio To: 'oliver2, andy'; '[EMAIL PROTECTED] ' Cc: ''Dan Milstein' ' Sent: 3/6/01 7:51 PM Subject: RE: FW: problem w/ ajp13 - if Tomcat is shutdown Here's exactly what I did to reproduce the problem. Again, I'm running this on a Solaris 2.8 SunOS machine, using JDK1.2.2, Apache 1.3.14, Tomcat 3.2.1. 1. Start Apache 2. Start Tomcat 3. Start hitting Apache with multiple requests, such as /example/servlet/HelloWorldExample. Make sure there are some connections opened from Apache to Tomcat. To make sure, you can do netstat -a | grep Tomcat port where Tomcat port is the ajp13 port. It should show some socket in ESTABLISHED state. 4. While the connections are in the ESTABLISHED state (this should be the state because ajp13 reuse connections), shutdown Tomcat. Now you will notice the same netstat will show some sockets in FIN_WAIT2 and CLOSE_WAIT state. 5. Now restart Tomcat. 6. Repeat step 3. You will get Internal Server Error, up to the number of children Apache has. After that number, the page will be served. Attached is the server.xml, workers.properties, httpd.conf. My test servlet is called /mytest/servlet/testServlet but I think you can try it with any kind of servlet. I have been trying to code up the retry I mentioned below. I think I got it working. I just need to clean up the code some more. shinta -Original Message----- From: oliver2, andy [ mailto:[EMAIL PROTECTED] mailto:[EMAIL PROTECTED] ] Sent: Tuesday, March 06, 2001 6:33 PM To: 'Shinta Tjio '; '[EMAIL PROTECTED] ' Cc: ''Dan Milstein' ' Subject: RE: FW: problem w/ ajp13 - if Tomcat is shutdown I was running recently with that exact same configuration but did not experience that problem. Can you show some config files. -Andy -Original Message- From: Shinta Tjio To: [EMAIL PROTECTED] Cc: 'Dan Milstein' Sent: 3/6/01 7:01 PM Subject: RE: FW: problem w/ ajp13 - if Tomcat is shutdown I am using Tomcat 3.2.1, Apache 1.3.14, running on Solaris 2.8, Sun machines. After various attempts of debugging this, I have more information. 1. Even though I'm setting the worker's property cache_size to default (1), I'm finding there are up to 6 connections opened from Apache to Tomcat. I deduce this by looking at the mod_jk.conf and by doing netstat. I finally find out, this is so because my Apache is set to spawn minimum of 6 children and each of those children are making separate connections to Tomcat. This is very bad because, I ended up having to reload 6 times before Tomcat starts serving me the page again. Each time it uses a different Apache children that has defunct socket. So the more Apache children I have, the longer it takes me to recover from this problem. 2. It seems when Tomcat dies restarts, the send() called by ajp13's jk_tcp_socket_sendfull() does not get an error. But the recv() does get an error, with errno ECONNRESET. After which, the socket is properly closed. 3. When I shutdown Tomcat, those sockets that were opened between Apache/Tomcat showed up in state CLOSE_WAIT, and FIN_WAIT2. I think this is normally solved by calling the shutdown() API after closing the socket. However, this would have to be done from the Tomcat side in Ajp13ConnectionHandler.java. I can't find the corresponding method of Socket in Java. So.. based on all of these, the only fix I can think of putting is to make mod_jk retry the send() if recv() comes back with an error ECONNRESET. The retry should happen after the ol
RE: FW: problem w/ ajp13 - if Tomcat is shutdown
I was running recently with that exact same configuration but did not experience that problem. Can you show some config files. -Andy -Original Message- From: Shinta Tjio To: [EMAIL PROTECTED] Cc: 'Dan Milstein' Sent: 3/6/01 7:01 PM Subject: RE: FW: problem w/ ajp13 - if Tomcat is shutdown I am using Tomcat 3.2.1, Apache 1.3.14, running on Solaris 2.8, Sun machines. After various attempts of debugging this, I have more information. 1. Even though I'm setting the worker's property cache_size to default (1), I'm finding there are up to 6 connections opened from Apache to Tomcat. I deduce this by looking at the mod_jk.conf and by doing netstat. I finally find out, this is so because my Apache is set to spawn minimum of 6 children and each of those children are making separate connections to Tomcat. This is very bad because, I ended up having to reload 6 times before Tomcat starts serving me the page again. Each time it uses a different Apache children that has defunct socket. So the more Apache children I have, the longer it takes me to recover from this problem. 2. It seems when Tomcat dies restarts, the send() called by ajp13's jk_tcp_socket_sendfull() does not get an error. But the recv() does get an error, with errno ECONNRESET. After which, the socket is properly closed. 3. When I shutdown Tomcat, those sockets that were opened between Apache/Tomcat showed up in state CLOSE_WAIT, and FIN_WAIT2. I think this is normally solved by calling the shutdown() API after closing the socket. However, this would have to be done from the Tomcat side in Ajp13ConnectionHandler.java. I can't find the corresponding method of Socket in Java. So.. based on all of these, the only fix I can think of putting is to make mod_jk retry the send() if recv() comes back with an error ECONNRESET. The retry should happen after the old socket is properly closed. Anyone wants to comment? shinta -Original Message- From: Dan Milstein [ mailto:[EMAIL PROTECTED] mailto:[EMAIL PROTECTED] ] Sent: Tuesday, March 06, 2001 12:00 PM To: [EMAIL PROTECTED] Subject: Re: FW: problem w/ ajp13 - if Tomcat is shutdown What version of TC are you using? What version of Apache? I would look into the mod_jk docs -- I think this is the spec'd behavior (which, admittedly, is not great, but that makes it more of a feature request than a bug ;-). With ajp13, Apache opens up a persistent TCP/IP connection TC -- if TC restarts, I think that connection may just hang up and then timeout (since Apache doesn't know that TC has restarted). If anyone wants to work on this, you would have the undying thanks of the rest of the TC community -- having to restart Apache all the time bugs a *lot* of people. -Dan Shinta Tjio wrote: I'm having problem with mod_jk if ajp13 is used. The problem is often reproduced when Tomcat is shut down without Apache being shut down. When a request is fired through Apache as soon as Tomcat starts, I often get Internal Server Error. The mod_jk.log will have the following: [jk_uri_worker_map.c (344)]: Into jk_uri_worker_map_t::map_uri_to_worker [jk_uri_worker_map.c (406)]: jk_uri_worker_map_t::map_uri_to_worker, Found a match ajp13 [jk_worker.c (123)]: Into wc_get_worker_for_name ajp13 [jk_worker.c (127)]: wc_get_worker_for_name, done found a worker [jk_ajp13_worker.c (651)]: Into jk_worker_t::get_endpoint [jk_ajp13_worker.c (536)]: Into jk_endpoint_t::service [jk_ajp13.c (346)]: Into ajp13_marshal_into_msgb [jk_ajp13.c (480)]: ajp13_marshal_into_msgb - Done [jk_ajp13_worker.c (203)]: connection_tcp_get_message: Error - jk_tcp_socket_recvfull failed [jk_ajp13_worker.c (619)]: Error reading request [jk_ajp13_worker.c (489)]: Into jk_endpoint_t::done If I hit reload multiple times, eventually Tomcat will serve the servlet fine. Did anyone see this problem before? Is there anyway around this? shinta -- Dan Milstein // [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Tomcat ready for primetime (was RE: some benchmarks)
Benchmarks don't mean a whole lot to me as they're all a bit on the subjective and software has gotten a little too complex to say "this is faster/better or more stable than this" because different situations highlight different things/needs. I mean Microsoft does benchmarks where they beat Oracle and have 99% uptime...haven't witnessed it myself though. I converted (mostly by removing all the "getRealPath") a legacy jserv application to tomcat, it did not use JSPs mind you. The site got ~150,000 hits a day. Tomcat kept up fine and was not noticably slower or faster, as far as the eye could see it was near-instantanious. (keep in mind I had no real bandwidth constraints when measuring this..those of you on old 56k modems probably don't know what that means) Later when rewriting in JSPs/beans/EJBs. Tomcat and Jboss were actually slower than the original application on initial startup but after about half an hour it was equal the speed if not faster. (but using perception its hard to say). I'd guess it was faster due to the number of apache connections open at once (dropped to ~35 from about 100). Some of this is due to the improvements in the application. I did have a number of performance problems with both editions of the application, but I traced them all back to the database (which had stack overflows and memory leaks) or the legacy application (which had synchronization problems). What other problems I had were usually either a configuration issue (documentation on both tomcat/jboss projects leaves much to be desired, I'd be happy to contribute to this effort at some point, however you have to know what the heck you're talking about well enough to explain it before you can document something or have greater than usual support for doing an un-sexy project like documentation from volunteers,in my humble opinion this is where the Suns and IBMs need to donate most...donate experienced tech writers and people who full time just analyze the stuff and document..that will win greater commercial support). So the bottom line is in my opinion Tomcat 3.21 has reached prime-time capability. If you're (somewhat off topic but related since they often get bundled) willing to load a "pre" then JBoss 2.1pre can be used, 2.0 isn't so ready due to various intermittant problems and the documentation which is confused between about 3 versions of it leaves so much to be desired...some effort is being made in changing this but they need to go through it with a fine tooth comb and say "still true/not true". Lastly although mod_jk is a royal pain to switch to, its worth doing. I had little luck getting the mod_jserv-tomcat-apache combination to work. (work means live more than an hour) Note that if you do uploads with Multi-part requests you'll need a direct-to-tomcat method of doing them as mod_jk breaks them. FYI: first edition was primarily servlet driven/interperated in-house tag language with jserv and apache. Second edition was the same except adapted for tomcat and mod_jk/apache Third edition was written in JSPs with some regular beans which front ended some EJBs. No servlets were used as this was a "view only" project and I'd intended to have a forth edition once I could redo the database schema. Equipment was a couple of load balanced Sparcs with another dual-processor sparc back end running Solaris 7. So anyhow thats my subjective evidence that tomcat 3.21 is ready for primetime while so many state otherwise. -Andy -Original Message- From: GOMEZ Henri To: [EMAIL PROTECTED] Sent: 3/3/01 6:54 PM Subject: RE: Some benchmarks I need to choose for my company the "next generation" servlet-engine. For now we are using JRUN. I am doing benchmark to choose the next one. choices for me are : JRUN, RESIN... not Tomcat as it is considered not stable and slow compare to the two others... When you say that Tomcat is slow could you give numbers. ie : tomcat served 1000 req/s and Resin 3000 req/s - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
