Re: concern about Apache + mod_jk + Tomcat cluster
Hi, Make sure you have set the MaxProcessors property of the AJP13 Connector in server.xml to an equal or higher value as specified in MaxClients of the httpd.conf. llap, julian - Original Message - From: YOU, JERRY (SBCSI) [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Wednesday, January 15, 2003 6:04 PM Subject: concern about Apache + mod_jk + Tomcat cluster Hi, I installed the Apache1.3.27, mod_jk1.2.1 and Tomcat4.1.18 recently on our Solaris6 machine. The approach is that let 1 apache as web server dispatches requestes to the 3 tomcat server instances. There is no error in the configuration, and install. But when I was load-testing the application, I noticed that there were lots of error message shown in the mod_jk file, although all the requests were dispatched to the tomcat servers and responded with 200. I then changed the 3 tomcat servers' configure as following: Connector className=org.apache.ajp.tomcat4.Ajp13Connector port=11009 minProcessors=1 maxProcessors=1 acceptCount=10 debug=1/ So now every Tomcat can only accept 1 request at the same time. I then sent 3 concurrent requests to the cluster: tomcat21, tomcat22, tomcat23. From the debug/log file, I think the mod_jk and tomcats are working like : 1, 3 requests reaches mod_jk, mod_jk sends requests to tomcat21 2, tomcat21 accepts the first one and rejects the other 2, 3, mod_jk logs errors in mod_jk.log, reports the tomcat is down or network problem. 4, mod_jk then sends the 2 to tomcat22 5, tomcat22 accepts 1 and rejects the other. 6, mod_jk again logs errors. 7. mod_jk sends the alst one to tomcat23, 8, tomcat 23 accepts it. I think there is nothing wrong with this procedure, but besides the annoying error messages, the whole performance is poor due to the time spent in the probes. I also suspect that the socket connection in Solaris6 is too slow, for some reason. I have questions for those who have the tomcat cluster in there production site: how about the performance in your site? Is there anything wrong with my configuration or should I use JK2 to improve performance? The configuration files and log files are attached with this email. OS: Solaris 6 Apache1.3.27, Tomcat 4.1.18, mod_jk1.2.1( I can not find the binary mod_jk at the apache.org site under solaris6 directory, so, I download the one in Solaris8 dir). Thanks, Jerry You tomcat_23_catalina.log the_change_to_httpd.conf workers.properties change_to_tomcat21_server.xml tomcat_21_catalina.log tomact_22_catalina.log -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: How cai I tell if jikes is being used?
You are using jikes. When using javac, compile errors always (as far as i know) include the line: org.apache.jasper.JasperException: Unable to compile class for JSPNote: sun.tools.javac.Main has been deprecated. The phrase Semantic Error and the notation varsess_jsp.java:69:3:69:13: is also unique to jikes For example (same file compiled with javac jikes): JAVAC: org.apache.jasper.JasperException: Unable to compile class for JSPNote: sun.tools.javac.Main has been deprecated. An error occurred at line: 5 in the jsp file: /inc5.jsp Generated servlet error: /appl/jakarta-tomcat-4.0.4/work/Standalone/localhost/klon/inc5$jsp.java:73: Method ccurrentTimeMillis() not found in class java.lang.System. out.print( System.ccurrentTimeMillis() ); ^ 1 error, 1 warning JIKES: org.apache.jasper.JasperException: Unable to compile class for JSP An error occurred at line: 5 in the jsp file: /klon/inc5.jsp Generated servlet error: /appl/tomcat-ausgabe/work/Standalone/localhost/_/klon/inc5$jsp.java:73:28:73 :54: Semantic Error: No method named ccurrentTimeMillis was found in type java.lang.System. However, there is an accessible method currentTimeMillis whose name closely matches the name ccurrentTimeMillis. - Original Message - From: Marco Bucciarelli [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Tuesday, January 07, 2003 6:12 PM Subject: How cai I tell if jikes is being used? I found the same question in the mailing list but no answer yet. I am trying jikes and everything works, but how can I tell if javac or jikes is used to compile jsp? I use Tomcat4.1.18 on RH Linux 7.0. I inserted the lines in web.xml and in /usr/bin/dtomcat to instruct Tomcat to use jikes, as described in the documentation. If I compile a jsp with a syntactic error, I get two different answers (more verbose using javac). With jikes (supposing it is used) I get this: Generated servlet error: [javac] Compiling 1 source file [javac] /var/tomcat4/work/Standalone/localhost/commesse/varsess_jsp.java:69:3:69:13: Semantic Error: Type org.apache.jsp.CommesseAMa was not found. There is allways written [javac], so how should I be sure I am using jikes? With the same configuration on Windows (catalina.bat + web.xml) I get an error saying jikes does not support the encoding option, so perhaps this assures me that on Linux I am using jikes. Thank you, bye. Marco. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Memory Usage and Garbage Collection
Looking at the jasper source of tomcat 4.0.4 releasing jsp's seems to be reasonable easy to implement: The Jsp's classloader, the class and the actual jsp-servlet instance are all put together in a JspServletWrapper-Object which itself is stored in the JspServlet (the Servlet used to executing jsps) using a Hashtable. One could replace the hashtable with a LRU-Cache or anything. Since each jsp is loaded using a separate classloader, removing the Wrapper removes the reference to the instance, it's class and it's loader, which should enable the class garbage collector to remove the class. Do you think this approach is reasonable? Does this part of the implementation differ with Jasper2? This is a feature I could really use well. llap, julian - Original Message - From: Craig R. McClanahan [EMAIL PROTECTED] To: Tomcat Users List [EMAIL PROTECTED]; [EMAIL PROTECTED] Sent: Friday, January 03, 2003 1:12 AM Subject: Re: Memory Usage and Garbage Collection On Thu, 2 Jan 2003, Brandon Cruz wrote: Date: Thu, 2 Jan 2003 16:16:23 -0600 From: Brandon Cruz [EMAIL PROTECTED] Reply-To: Tomcat Users List [EMAIL PROTECTED], [EMAIL PROTECTED] To: Tomcat Users List [EMAIL PROTECTED] Subject: Memory Usage and Garbage Collection Do loaded jsp pages and/or class files ever get garbage collected when tomcat is running? It's legal for servlet containers to destroy and release servlets and JSP pages while the server is running, but Tomcat doesn't currently do so. Once a servlet or JSP is loaded, it stays loaded until you reload that particular webapp or you shut Tomcat down. We have a production server with several hundred virtual hosts per host, each with a fair share of jsp pages and with moderate to low traffic per host. As time goes on, the amount of memory being used constantly grows. It starts off around 60MB, then goes higher and higher, getting up to around 100MB after a couple days. The regular GC seems to usually clean up around 2MB ([GC 99493K-97502K(204544K), 0.0243521 secs]) and the Full GC seems to clean up less than that ([Full GC 97388K-97187K(204544K), 2.4269915 secs]). Since I have the -Xmx and -Xms set to 200MB, the 204544K number never gets resized, but the number before the - seems to slowly and steadily rise. Full GC seems to run quite often, every few seconds, GC runs once in a while, but spits out about 50 lines at once every time it runs. Is this normal? Shouldn't Full GC only run once in a while? I am starting to think that as classes and jsp's are loaded, they stay in memory and are never released until tomcat is restarted, which means that there is eventually a point where all the classes will load and I just need to have enough memory to support that without having to use swap space. It's not just the classes -- it's the object instances created from those classes that take up space (the bytecodes of the class itself exist only once). The problem occurs when the memory usage number before the - gets up to about 130. The system is using swap space and eventually out of memory errors start showing up. Any ideas? More Ram, more tuning, different site architecture? If you're using swap space, you probably have your max heap size (-Xmx) too large for the amount of physical memory that is available. I'd definitely start by either reducing -Xmx or increasing the amount of physical RAM. If reducing -Xmx gives you OutOfMemoryException errors, then increasing RAM is the only option. The second thing I'd do is review my applications for places where they might be maintaining references to data in between requests, either in instance variables of the servlet or JSP class or by keeping too many things in the user's session for too long. If there are such references, your user data objects cannot be GC'd and you'll end up with exactly the pattern you describe (slowly increasing memory use). Thanks in advance? Brandon Craig -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: reducing tomcat jasper memory footprint
Thanks for your Feedback! I will look into your suggested approch using filters. answers inline - Original Message - From: Will Hartung [EMAIL PROTECTED] To: Tomcat Users List [EMAIL PROTECTED] Sent: Thursday, January 02, 2003 11:27 PM Subject: Re: reducing tomcat jasper memory footprint There are a lot of issues that show up here. 1) Using the JSP means that the entire article text (among other things) is being cached into RAM. 2) Some of the pages are popular enough that they are getting moved into the permanent area of memory, and thus avoiding the routine, cheap GCs. 3) The question whether Tomcat is somehow holding on to the JSP references to prevent them from being GC'd at all (I don't think this is the case, but you never know). As of 4.0.4 tomcat keeps a reference to every generated servlet, so increasing the memory size only delays the OutOfMemoryError. As for solutions, there are several, none of which are particularly elegant I don't think. First, of course, Buy more RAM, also pronounced Let's make our Full GC's take even LONGER!. Another is to simply reboot Tomcat during a quiet time. At least this way, the down time is predictable rather than having it Crash at an unscheduled time. If the restart time is fast enough, and the site quiet enough, this may effectively solve the issue. You mentioned that the system is running several days reliably now, so, perhaps a nightly restart is not a horrible concession. Another is to mirror the site behind some kind of load balancer so that restarting the site does not actually affect users, and then go to solution one. Oh boy, more hardware to configure. In fact we are using loadbalancing using apache 1.3.26, mod_jk, and 3 tomcat instances. Every night one tomcat get's restarted. Basically we use the lb-options local_worker local_worker_only to disable a tomcat instance at midnight and restart it at 4:00. Otherwise the big problem with restarting tomcat is loss of our session-data. Saving and restoring the data in the SESSIONS.ser file doesn't help, since the loadbalancer routes the web clients to another tomcat instance where they get another sessionId. I once experimented with tomcat clustering using the source from http://www.filip.net/tomcat/ but this was some months ago and didn't work very well at this early stage . You can rengineer the site. If your JSPs are reasonably regular to the point where you can write fairly simple filters to extract the actual content without resorting to crafting a JSP parser, then that is a good first step. So, going on the crass assumption that getting the article text out of your generated JSPs is not an onerous task, then the next step, to me, would be to stick a servlet Filter in front of every request. This Magic Filter (a notable anti-pattern, but...) is configured so that you will not have to actually update and rewrite all of the zillion URLs scattered throughout the site. So, www.yoursite.com/area/document.jsp in the old site is the same in the new site. The Magic Filter determines if the JSP file is a real jsp (no doubt you have some JSPs that do something other than dump static articles), versus one of your generated documents. If it is one of your generated documents, then the Magic Filter rips it apart, caches it perhaps (the ripped text), and then serves it up in a new shiny generic way as should have been done originally. If not, you let the Filter drop through and pass on so the container can handle the JSP requiest and go its merry way. Ideally, this can be done with very little change to the site, and certainly no change to the production CMS, it's ignorant of the change. Your web.xml simply has a new Filter element, and voila! I am not suggesting that this is easy or painless, but if your generated JSPs are able to be easily torn apart, then I think it's viable and practical. Perhaps your CMS JSP template can be recoded to add some comments (like !-- ARTICLE START TEXT-- This is my article !-- ARTICLE END TEXT --) that makes it easy to find articles. Perhaps you can then REGENERATE all of your older content to use the new template. You'd like to think that your CMS will allow this (kind of the whole point of a CMS at some level, isn't it?). Or, if you can not regenerate your older content, have the Magic Filter detect old vs. new and simply execute the old ones (as noted above), and filter the new ones. If your site is mostly newer content, then the old stuff will drift away and be less of a problem over time. Once up and running, your Magic Filter can cache and keep track of the status of various JSPs it encounters so as not to have to rework them each time. I would vote for the restart nightly technique and look into ways of tweaking the CMS system to spit out something you can use, but that's me. The other problem with this technique is that it is doing processing at run time which could
reducing tomcat jasper memory footprint
Hi, I'm using Apache 1.3.26 and 3 tomcat 4.0.4 instances with AJP13 loadbalancing . Our application is a CMS where all the published articles are generated offline as JSP-Files, one jsp per article. We had hige problems with the memory footprint. Due to the fact that every jsp is generated as a class and there are about 200 new artices per day the permanent segment of the JVM heap gets filled with all the classes, and I get an OutOfMemoryError. My workaround for now is setting -XX:PermSize and --XX:MapPermSize to higher values, but this just delays application hang-up. With 64 megs of permSize our Server had an approx. uptime of 1 day now it's about 3-4 days. Is there any way to unload jsp-Files (unload the class) ? llap, julian
Re: reducing tomcat jasper memory footprint
If I'd only known about this problem a few months earlier Sad truth is that I can't change this (too) jsp-centric design. llap, julian - Original Message - From: Wagoner, Mark [EMAIL PROTECTED] To: 'Tomcat Users List' [EMAIL PROTECTED] Sent: Monday, December 30, 2002 8:48 PM Subject: RE: reducing tomcat jasper memory footprint I don't have an answer to your exact question, but given the numbers you cite I would try to come up with an alternative design. Perhaps you can create one JSP page that uses dynamic includes to incorporate the text of the article? Just a thought. -Original Message- From: Julian Löffelhardt [mailto:[EMAIL PROTECTED]] Sent: Monday, December 30, 2002 2:37 PM To: Tomcat Users List Subject: reducing tomcat jasper memory footprint Hi, I'm using Apache 1.3.26 and 3 tomcat 4.0.4 instances with AJP13 loadbalancing . Our application is a CMS where all the published articles are generated offline as JSP-Files, one jsp per article. We had hige problems with the memory footprint. Due to the fact that every jsp is generated as a class and there are about 200 new artices per day the permanent segment of the JVM heap gets filled with all the classes, and I get an OutOfMemoryError. My workaround for now is setting -XX:PermSize and --XX:MapPermSize to higher values, but this just delays application hang-up. With 64 megs of permSize our Server had an approx. uptime of 1 day now it's about 3-4 days. Is there any way to unload jsp-Files (unload the class) ? llap, julian -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: reducing tomcat jasper memory footprint
Hi, I use jikes to compile the pages. Since raising the JVM permanent segment size delays the error the problem seems to come from the sheer size of the loaded class files. So theorectically it shouldn't matter wheter the pages are precompiled or not. Anyway I 'm about to set up a test specifically for this, to measure how many pages can be loaded before an error occurs. llap, julian - Original Message - From: Jerome Lacoste (Frisurf) [EMAIL PROTECTED] To: Tomcat Users List [EMAIL PROTECTED] Sent: Monday, December 30, 2002 8:51 PM Subject: Re: reducing tomcat jasper memory footprint Could this be also related to the leaks of the java compiler? Did you try to precompile the JSPs before deploying them (using JSPC) ? Perhaps does that help? Jerome On Mon, 2002-12-30 at 20:37, Julian Löffelhardt wrote: Hi, I'm using Apache 1.3.26 and 3 tomcat 4.0.4 instances with AJP13 loadbalancing . Our application is a CMS where all the published articles are generated offline as JSP-Files, one jsp per article. We had hige problems with the memory footprint. Due to the fact that every jsp is generated as a class and there are about 200 new artices per day the permanent segment of the JVM heap gets filled with all the classes, and I get an OutOfMemoryError. My workaround for now is setting -XX:PermSize and --XX:MapPermSize to higher values, but this just delays application hang-up. With 64 megs of permSize our Server had an approx. uptime of 1 day now it's about 3-4 days. Is there any way to unload jsp-Files (unload the class) ? llap, julian -- Jerome Lacoste (Frisurf) [EMAIL PROTECTED] CoffeeBreaks -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: reducing tomcat jasper memory footprint
Hi, My problem isin't javac memory leakes. Due to the apache/tomcat documentation I was aware of this an setup jikes as my jsp compiler. I'm also using JDK 1.4.1 so the javac issues should be solved, nonetheless. The main problem is as follows: 1. Every article every page in general is a jsp page 2. All the pages are generated by a legacy CMS-System (imperia) and I can't change the structure of it's works. 3. Every jsp page, once loaded, consumes memory, since the class remains loaded. 4. We have 1000s of pages , every day some 200-300 new, so memory use increases. Conclusion: The way we use jsp's for a cms is faulty. But I can't do anything about this. Increasing permSize of the JVM helps a lot. Maybe it would be a good idea to include some hints about -XX:MaxPermSize and XX:PermSize into the documentation because it really helps lessen the problems. But: Is there any generic way to get a stable tomcat with huge number of jsp's ? Thanks for all ya feedback llap + happy new year... julian - Original Message - From: Remy Maucherat [EMAIL PROTECTED] To: Tomcat Users List [EMAIL PROTECTED] Sent: Monday, December 30, 2002 9:40 PM Subject: Re: reducing tomcat jasper memory footprint Paul Yunusov wrote: On Monday 30 December 2002 02:37 pm, Julian Löffelhardt wrote: Hi, I'm using Apache 1.3.26 and 3 tomcat 4.0.4 instances with AJP13 loadbalancing . Our application is a CMS where all the published articles are generated offline as JSP-Files, one jsp per article. We had hige problems with the memory footprint. Due to the fact that every jsp is generated as a class and there are about 200 new artices per day the permanent segment of the JVM heap gets filled with all the classes, and I get an OutOfMemoryError. My workaround for now is setting -XX:PermSize and --XX:MapPermSize to higher values, but this just delays application hang-up. With 64 megs of permSize our Server had an approx. uptime of 1 day now it's about 3-4 days. Is there any way to unload jsp-Files (unload the class) ? llap, julian JAVAC leaks memory every time a JSP class is compiled. The more JSPs are compiled or the more often JSP classes are compiled, the more memory is leaked. You exacerbate this problem by generating a JSP per article often. IMHO, generating a JSP per article is misusing the technology. JSP is a templating solution whereas one JSP describes a layout of any number of end documents. I suggest you change your software to generate an HTML file per artcile rather than a JSP. Maybe it's abusing the technology, but it really should work fine. Workarounds for the problem include using jikes, or using javac out of process (I don't quite remember how it is configured; since Jasper 2 uses Ant javac task to compile, it should be in the Ant docs on the javac task). Remy -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Tomcat stability problem
Hi, I'm using jdk 1.4.1 on redHat Linux, and -Xincgc didn't do that well. I was experimenting with java gc settings and -Xincgc dropped my overall performance about 75%. Maybe it works better with other JVM/OS combinations but it seems that when using linux one is best of with the -client VM and no fancy gc settings ( I also think that the incremental garbage collector would be enabled by default if it were any good) Beside incrementig -Xmx and -Xms I had great succcess with -XX:PermSize and -XX:MaxPermSize to resolve several memory issues I had when using to many distinct JSP-pages. llap, julian - Original Message - From: Ben Glorie [EMAIL PROTECTED] To: Tomcat Users List [EMAIL PROTECTED] Sent: Saturday, December 28, 2002 6:33 PM Subject: RE: Tomcat stability problem GC delay certainly sounds plausible, I'll try to set the -Xinccg option as suggested by Bill. We're running Linux 7.3 and Java 1.4.1_01. Is this combination also sensitive to SMP problems? If that would be the problem, what would I have to do? Thanks to you all for the suggestions so far, which have all been very helpful. -Original Message- From: Noel J. Bergman [mailto:[EMAIL PROTECTED]] Sent: Saturday, December 28, 2002 5:38 AM To: Tomcat Users List Subject: RE: Tomcat stability problem We're running Tomcat 4.1.12 on a dual-proc PIII with 512MB RAM. Which JVM and OS? You are running an SMP box. Sun JVM 1.4.0, for example, was notorious for SMP issues on linux. --- Noel -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: tomcat,mod_jk loadbalancing
- Another idea: We are operating a newspaper website, and offering our users to log into our system to get additional services. Of course most people won't log in because they just want to read the news. Depending on how you code your application you will configure accordingly. Are you using encodeURL()? If not, your users are probably bouncing around with each click even when they are not logged in. In my opinion, you should really maintain a session for each user whether they login or not. This way, they won't be connecting to a new Tomcat thread with each click. You can set the default session to expire in 3 mins or some other short time in web.xml. Then for those who logins, the web application expires in much longer period. There were just posts covering this topic. This should decrease your Tomcat threads. We maintain our sessions using cookies. Using some web stress tools, I also found out that the loadbalancer sometimes has problems working small scale. it's not uncommon that it will route 10-20 sequential requests (without sessionid) to the samr tomcat instance. These requests then remain bound to this tomcat due to the sticky session functionality (which is good). I just hoped the load-balancer would distribute the requests more evenly when most of the requests don't have a sessionid and thus aren't bound to a specific tomcat instance. llap, julian -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
tomcat,mod_jk loadbalancing
Hi, I'm using an Apache --- 3 Tomcats loadbalancing scenario with Apache 1.3.26 mod_jk 1.2.0 3 x tomcat 4.0.4 The tomcats are configured with: Xmx: 512m AJP13 Connector allows for 800 connections Each worker is set up like this and added to an loadbalanced worker worker.host1.port=8009 worker.host1.host=host1 worker.host1.type=ajp13 worker.host1.lbfactor=10 worker.host1.socket_timeout=300 I keep experiencing the following problems: -The threadcount of each tomcat process keeps increasing (never decreases) - The memory usage keeps also increasing - When examinig the tomcat process with ps -aux I see many(200) threads older than 1 day. I thought that teh socket_timeout would always stop such threads after 5 minutes The AJP-Connectior threads keep throwing exceptions like: 2002-12-09 16:58:59 Ajp13Processor[8009][583] process: invoke java.net.SocketException: Socket closed at java.net.SocketOutputStream.socketWrite0(Native Method) at java.net.SocketOutputStream.socketWrite(SocketOutputStream.java:92) at java.net.SocketOutputStream.write(SocketOutputStream.java:126) at org.apache.ajp.Ajp13.send(Ajp13.java:525) at org.apache.ajp.RequestHandler.finish(RequestHandler.java:495) at org.apache.ajp.Ajp13.finish(Ajp13.java:395) at org.apache.ajp.tomcat4.Ajp13Response.finishResponse(Ajp13Response.java:196) at org.apache.ajp.tomcat4.Ajp13Processor.process(Ajp13Processor.java:464) at org.apache.ajp.tomcat4.Ajp13Processor.run(Ajp13Processor.java:551) at java.lang.Thread.run(Thread.java:536) 2002-12-09 13:09:21 Ajp13Processor[8009][349] process: invoke java.lang.IllegalArgumentException: Cookie name path is a reserved token at javax.servlet.http.Cookie.init(Cookie.java:185) at org.apache.ajp.tomcat4.Ajp13Request.addCookies(Ajp13Request.java:189) at org.apache.ajp.tomcat4.Ajp13Request.setAjpRequest(Ajp13Request.java:148) at org.apache.ajp.tomcat4.Ajp13Processor.process(Ajp13Processor.java:446) at org.apache.ajp.tomcat4.Ajp13Processor.run(Ajp13Processor.java:551) at java.lang.Thread.run(Thread.java:536) - When a tomcat instance gets into problems some connections still seem to work while others emit: 2002-12-09 13:32:25 Ajp13Processor[8009][155] process: invoke java.lang.OutOfMemoryError problem is that the mod_jk module (in the apache server) sometimes doesn't notive that a tomcat instance has problems and keeps sending connectuions to this particular instance , thereby freezing the whole cluster. -- Now my question is: Do you think that upgrading to some other version of tomcat, mod_jk, apache .. would solve some of my problems. Any experience with tomcat load-balancing under high -loads (Currently ~1 million pageviews/day). Any help would be appreciated? llap, julian löffelhardt - -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
mod_jk changes 1.2.0 - 1.2.1
Hi, stupid question: where can I find a changelog regarding the changes in mod_jk 1.2.0 -- 1.2.1 ? llap, julian
Question about an AJP error
Hi, To all the mod_jk AJP guys out there I have a question :) I'm using mod_jk 1.2.0 , apache 1.3.26 tomcat 4.0.4. I use apache as load-balancer for my (3) tomcats. Besides some system hang-ups now and then it works fine. Could anybody please explain me the source of ajp errors like this one: 2002-12-09 14:48:14 Ajp13Processor[8009][327] process: invoke java.net.SocketException: Socket closed at java.net.SocketOutputStream.socketWrite0(Native Method) at java.net.SocketOutputStream.socketWrite(SocketOutputStream.java:92) at java.net.SocketOutputStream.write(SocketOutputStream.java:126) at org.apache.ajp.Ajp13.send(Ajp13.java:525) at org.apache.ajp.RequestHandler.finish(RequestHandler.java:495) at org.apache.ajp.Ajp13.finish(Ajp13.java:395) at org.apache.ajp.tomcat4.Ajp13Response.finishResponse(Ajp13Response.jav a:196) at org.apache.ajp.tomcat4.Ajp13Processor.process(Ajp13Processor.java:464 ) at org.apache.ajp.tomcat4.Ajp13Processor.run(Ajp13Processor.java:551) at java.lang.Thread.run(Thread.java:536) I've read in the list that it's not uncommon for this error to occur on a high-volume site about 20-30 times a day. Problem is I'm having houndreds of them (one error/5 minutes) a day. From readming the mailing list archives I got the impression this error is well known, but I couldn't find a posting explaing the details (and how to get rid of it). llap, julian löffelhardt
Re: tomcat,mod_jk loadbalancing
Hi, Thanks for your help! 2 additional questions: - if 1.2.0 doesn't use socket_timeout could I use cache_timeout ? load-balancing seems quite lost without this settings, because apache uses way to much AJP connectors on all load-balanced machines. So when the load get's high, either it kills all tomcat instances or get's stuck itself with some tomcat's not properly responding. Could you give me an entry point to the mod_jk sources? - Another idea: We are operating a newspaper website, and offering our users to log into our system to get additional services. Of course most people won't log in because they just want to read the news. We don't need session information for the people who aren't logged in. Could I change all jsp's to contain %@ page session=false % and onyl start a session on the login page. I've read that the implicit session attribute isn't available for pages with session=false, but other than that functionality would remain the same. I guess this way I could dramatically reduce the number of open sessions. Are there any caveats to this idea or does it sound reasonable? Thanks for your response for your time!!! llap, julian löffelhardt - Original Message - From: Ricky Leung [EMAIL PROTECTED] To: Tomcat Users List [EMAIL PROTECTED] Sent: Tuesday, December 10, 2002 1:01 AM Subject: RE: tomcat,mod_jk loadbalancing I know the documentation says the socket_timeout is there since 1.2.0, but when I look at the source code, it seems to only read this configuration setting with 1.2.1. You might want to give that a try and also make sure that you invalidate your sessions when people logout (which helps). As for that error, if a user stops the browser from waiting then you will get that error. If your site is slow, then you might see more of that then because users will get inpatient waiting and waiting. Ricky -Original Message- From: Julian Löffelhardt [mailto:[EMAIL PROTECTED]] Sent: Monday, December 09, 2002 11:18 AM To: [EMAIL PROTECTED] Subject: tomcat,mod_jk loadbalancing Hi, I'm using an Apache --- 3 Tomcats loadbalancing scenario with Apache 1.3.26 mod_jk 1.2.0 3 x tomcat 4.0.4 The tomcats are configured with: Xmx: 512m AJP13 Connector allows for 800 connections Each worker is set up like this and added to an loadbalanced worker worker.host1.port=8009 worker.host1.host=host1 worker.host1.type=ajp13 worker.host1.lbfactor=10 worker.host1.socket_timeout=300 I keep experiencing the following problems: -The threadcount of each tomcat process keeps increasing (never decreases) - The memory usage keeps also increasing - When examinig the tomcat process with ps -aux I see many(200) threads older than 1 day. I thought that teh socket_timeout would always stop such threads after 5 minutes The AJP-Connectior threads keep throwing exceptions like: 2002-12-09 16:58:59 Ajp13Processor[8009][583] process: invoke java.net.SocketException: Socket closed at java.net.SocketOutputStream.socketWrite0(Native Method) at java.net.SocketOutputStream.socketWrite(SocketOutputStream.java:92) at java.net.SocketOutputStream.write(SocketOutputStream.java:126) at org.apache.ajp.Ajp13.send(Ajp13.java:525) at org.apache.ajp.RequestHandler.finish(RequestHandler.java:495) at org.apache.ajp.Ajp13.finish(Ajp13.java:395) at org.apache.ajp.tomcat4.Ajp13Response.finishResponse(Ajp13Response. java:196) at org.apache.ajp.tomcat4.Ajp13Processor.process(Ajp13Processor.java:464) at org.apache.ajp.tomcat4.Ajp13Processor.run(Ajp13Processor.java:551) at java.lang.Thread.run(Thread.java:536) 2002-12-09 13:09:21 Ajp13Processor[8009][349] process: invoke java.lang.IllegalArgumentException: Cookie name path is a reserved token at javax.servlet.http.Cookie.init(Cookie.java:185) at org.apache.ajp.tomcat4.Ajp13Request.addCookies(Ajp13Request.java:189) at org.apache.ajp.tomcat4.Ajp13Request.setAjpRequest(Ajp13Request.java:148) at org.apache.ajp.tomcat4.Ajp13Processor.process(Ajp13Processor.java:446) at org.apache.ajp.tomcat4.Ajp13Processor.run(Ajp13Processor.java:551) at java.lang.Thread.run(Thread.java:536) - When a tomcat instance gets into problems some connections still seem to work while others emit: 2002-12-09 13:32:25 Ajp13Processor[8009][155] process: invoke java.lang.OutOfMemoryError problem is that the mod_jk module (in the apache server) sometimes doesn't notive that a tomcat instance has problems and keeps sending connectuions to this particular instance , thereby freezing the whole cluster. -- Now my question is: Do you think that upgrading to some other version of tomcat, mod_jk, apache .. would solve some of my problems. Any experience with tomcat load-balancing under high
Re: tomcat,mod_jk loadbalancing
Hello, once again! I always thought I'm using mod_jk 1.2.0 sbecause that's displayed in the server-status. stupid me. mod_jk 1.2.0 indeed does contain the socket_timeout cache_timeout settings (I dont't know if they work, though) After downloading several versions of the connector sources and comparing them to the debug output in mod_jk.log I came to the conclusion that im using the Connector shipped in jakarta-tomcat-connectors-4.0.2-01. This version doesn't seem to have any timeout options. Documentation says mod_jk is independent of tomcat version, so I guess I could just update the Apache/mod_jk part of my system. Is this assumption correct I wouldn't want to switch to another tomcat, because chnages like this tend to create countless problems in regard to source compatibility. Thanks for your help! llap, julian - Original Message - From: Julian Löffelhardt [EMAIL PROTECTED] To: Tomcat Users List [EMAIL PROTECTED] Sent: Tuesday, December 10, 2002 1:29 AM Subject: Re: tomcat,mod_jk loadbalancing Hi, Thanks for your help! 2 additional questions: - if 1.2.0 doesn't use socket_timeout could I use cache_timeout ? load-balancing seems quite lost without this settings, because apache uses way to much AJP connectors on all load-balanced machines. So when the load get's high, either it kills all tomcat instances or get's stuck itself with some tomcat's not properly responding. Could you give me an entry point to the mod_jk sources? - Another idea: We are operating a newspaper website, and offering our users to log into our system to get additional services. Of course most people won't log in because they just want to read the news. We don't need session information for the people who aren't logged in. Could I change all jsp's to contain %@ page session=false % and onyl start a session on the login page. I've read that the implicit session attribute isn't available for pages wi th session=false, but other than that functionality would remain the same. I guess this way I could dramatically reduce the number of open sessions. Are there any caveats to this idea or does it sound reasonable? Thanks for your response for your time!!! llap, julian löffelhardt - Original Message - From: Ricky Leung [EMAIL PROTECTED] To: Tomcat Users List [EMAIL PROTECTED] Sent: Tuesday, December 10, 2002 1:01 AM Subject: RE: tomcat,mod_jk loadbalancing I know the documentation says the socket_timeout is there since 1.2.0, but when I look at the source code, it seems to only read this configuration setting with 1.2.1. You might want to give that a try and also make sure that you invalidate your sessions when people logout (which helps). As for that error, if a user stops the browser from waiting then you will get that error. If your site is slow, then you might see more of that then because users will get inpatient waiting and waiting. Ricky -Original Message- From: Julian Löffelhardt [mailto:[EMAIL PROTECTED]] Sent: Monday, December 09, 2002 11:18 AM To: [EMAIL PROTECTED] Subject: tomcat,mod_jk loadbalancing Hi, I'm using an Apache --- 3 Tomcats loadbalancing scenario with Apache 1.3.26 mod_jk 1.2.0 3 x tomcat 4.0.4 The tomcats are configured with: Xmx: 512m AJP13 Connector allows for 800 connections Each worker is set up like this and added to an loadbalanced worker worker.host1.port=8009 worker.host1.host=host1 worker.host1.type=ajp13 worker.host1.lbfactor=10 worker.host1.socket_timeout=300 I keep experiencing the following problems: -The threadcount of each tomcat process keeps increasing (never decreases) - The memory usage keeps also increasing - When examinig the tomcat process with ps -aux I see many(200) threads older than 1 day. I thought that teh socket_timeout would always stop such threads after 5 minutes The AJP-Connectior threads keep throwing exceptions like: 2002-12-09 16:58:59 Ajp13Processor[8009][583] process: invoke java.net.SocketException: Socket closed at java.net.SocketOutputStream.socketWrite0(Native Method) at java.net.SocketOutputStream.socketWrite(SocketOutputStream.java:92) at java.net.SocketOutputStream.write(SocketOutputStream.java:126) at org.apache.ajp.Ajp13.send(Ajp13.java:525) at org.apache.ajp.RequestHandler.finish(RequestHandler.java:495) at org.apache.ajp.Ajp13.finish(Ajp13.java:395) at org.apache.ajp.tomcat4.Ajp13Response.finishResponse(Ajp13Response. java:196) at org.apache.ajp.tomcat4.Ajp13Processor.process(Ajp13Processor.java:464) at org.apache.ajp.tomcat4.Ajp13Processor.run(Ajp13Processor.java:551) at java.lang.Thread.run(Thread.java:536) 2002-12-09 13:09:21 Ajp13Processor[8009][349] process: invoke
