if user's browser doesn't support Cookies, then where to store user's session information?
Hi, all I am using Tomcat 5.5.26 as the Web Server. I know the session information is stored in Cookies with the key JSESSIONID. But some browsers don't support Cookies. So my question is if user's browser doesn't support Cookies, then where to store user's session information? And besides session, how to store other user's state information, because HTTP protocol is a stateless protocol? Thanks.
RE: if user's browser doesn't support Cookies, then where to store user's session information?
There's an option somewhere to put the session ID into the URL. You can store state information in the session. Be careful, a browser with two windows will share the session between the two windows, so that a user may get very confusing results when you store currentpage in the session. Typically, the session is only used to store user login credentials, but not application data/state. You can store information on the client using hidden field on forms, which will send their data back when submitted. You can also add extra data in URLs, by adding parameters (e.g. href=nextpage?page=6queryid=10) or extra 'path' information (href=nextpage/10/6), which is very handy if you want to preserve user input across many links (any link will be relative to the URL that was used to reach this page, so ../7 could refer to page 7 of the same query). You can safely store a few kB of information in hidden fields or URLs without affecting performance. M. -Original Message- From: Peter Chen [mailto:peter.c...@aicent.com] Sent: dinsdag 12 januari 2010 10:01 To: users@tomcat.apache.org Subject: if user's browser doesn't support Cookies, then where to store user's session information? Hi, all I am using Tomcat 5.5.26 as the Web Server. I know the session information is stored in Cookies with the key JSESSIONID. But some browsers don't support Cookies. So my question is if user's browser doesn't support Cookies, then where to store user's session information? And besides session, how to store other user's state information, because HTTP protocol is a stateless protocol? Thanks. This message and attachment(s) are intended solely for use by the addressee and may contain information that is privileged, confidential or otherwise exempt from disclosure under applicable law. If you are not the intended recipient or agent thereof responsible for delivering this message to the intended recipient, you are hereby notified that any dissemination, distribution or copying of this communication is strictly prohibited. If you have received this communication in error, please notify the sender immediately by telephone and with a 'reply' message. Thank you for your co-operation. - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: if user's browser doesn't support Cookies, then where to store user's session information?
On 12/01/2010 09:00, Peter Chen wrote: Hi, all I am using Tomcat 5.5.26 as the Web Server. I know the session information is stored in Cookies with the key JSESSIONID. But some browsers don't support Cookies. So my question is if user's browser doesn't support Cookies, then where to store user's session information? Read chapter SRV.7 of the Servlet 2.4 specification. And besides session, how to store other user's state information, because HTTP protocol is a stateless protocol? On the client or in the URL are two that come to mind. How appropriate those approaches are will depend on your app. There is, of course, the make your app stateless option. Mark - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Running Tomcat 6 as a service
On 12/01/2010 04:10, Russell Collins wrote: I am using JRockit as my java runtime. When I manually start Tomcat, I have no problems with it. However, when I try to run Tomcat as a service with JRockit as my java runtime, I get an error that says that it cannot start the service. I looked in the service.bat file and I think that I may have found where this error is happening. The following lines are in the batch file rem Set the server jvm from JAVA_HOME set PR_JVM=%JAVA_HOME%\jre\bin\server\jvm.dll if exist %PR_JVM% goto foundJvm rem Set the client jvm from JAVA_HOME set PR_JVM=%JAVA_HOME%\jre\bin\client\jvm.dll if exist %PR_JVM% goto foundJvm JRockit does not have these entries in their java runtime directories. These are specific to Sun's implementation. The interesting thing is that I also run an Apache Geronimo serice using JRockit as the java runtime and it runs great. Can these lines be omitted? Are they crucial for Apache Tomcat to run as a service without issue? Do or do not, there is no try. - Yoda Maybe you could try it? p CONFIDENTIALITY NOTICE: The information contained in this electronic mail (email) transmission (including attachments), is intended by MCLANE ADVANCED TECHNOLOGIES for the use of the named individual or entity to which it is addressed and may contain information that is privileged, confidential and/or protected as a trade secret. It is not intended for transmission to, or receipt by, any individual or entity other than the named addressee(s). If you have received this email in error, please delete it (including attachments) and any copies thereof without printing, copying or forwarding it, and notify the sender of the error by email reply immediately. - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: JVM goes away
Perhaps not the best design but basically, yes. We have stored a fair amount of information in memory (session) to try to improve the speed of the application (so we don't go back to the disk as often.) At some point (probably never happen) I would like to take a look at the balance between storing information in session and the penalty for disk access but, like most people, just too busy right now. So, I have tried to cover this up with (relatively) cheap memory. Thanks for your thoughts. Carl - Original Message - From: Pid p...@pidster.com To: Carl c...@etrak-plus.com Sent: Tuesday, January 12, 2010 4:41 AM Subject: Re: JVM goes away On 12/01/2010 01:30, Carl wrote: Aha, for some reason, I thought perm gen was included in the general heap so the maximum for the two combined was constrained by the 2400m I had defined for the heap. Somewhere around 2:00AM (I am US east coast), I can restart the server with the new settings. I have taken several heap dumps (using Visual JVM) and nothing looked odd. Also, I can see (from Visual JVM) that the GC runs reasonably frequently when the heap grows (from users working) but the total heap is generally under 1GB. I wonder if the sneaky little bugger, under load, just pushes to OOM and I am running so close to the edge that I don't see it. Odd though, I have forced OOM issues in the past and they always showed up in catalina.out. Does your app actually need all that memory? p Thanks for your thoughts and help. Carl - Original Message - From: Pid p...@pidster.com To: users@tomcat.apache.org Sent: Monday, January 11, 2010 8:07 PM Subject: Re: JVM goes away On 11/01/2010 23:06, Peter Crowther wrote: 2010/1/11 Carlc...@etrak-plus.com: This is a new server, a Dell T110 with a Xeon 3440 processor and 4GB memory. I have turned off both the turbo mode and hyperthreading. The environment: 64 bit Slackware Linux java version 1.6.0_17 Java(TM) SE Runtime Environment (build 1.6.0_17-b04) Java HotSpot(TM) 64-Bit Server VM (build 14.3-b01, mixed mode) Tomcat: apache-tomcat-6.0.20 JAVA_OPTS=-Xms2400m -Xmx2400m -XX:PermSize=512m -XX:MaxPermSize=512m I have watched observed the memory usage and general performance with Java VisualVM and have seen nothing strange. GC seems to be performing well and the memory rarely gets anywhere near the max. The server runs well, idling along at 2-5% load, serving jsp's, etc. at a reasonable speed. Without warning and with no tracks in any log (Tomcat or system) or to the console, the JVM will just go away, disappear. Sometimes, the system will run for a week, sometimes for only several hours. Initially, I thought the problem was the turbo or hyperthreading but, no, the problem persists. When the JVM goes away, the memory that it held is still being held (as seen from top) but it is nowhere near the machine physical memory. The application has been running on an older server (Dell 600SC, 32 bit Slackware, 2GB memory) for several years and, while the application will throw exceptions now and then, it never crashed the JVM. This leads me to believe the problem has something to do with the 64 bit JVM but, with errors, I can't be certain and don't know what I can do about it except go back to 32 bit. I plan to reinstall Java tonight but, it would seem if the JVM were corrupted, it simply would not run. Any ideas are welcome. I'm with Andy: the Linux OOM killer would show those symptoms. With those settings, you're not leaving a lot of memory for the OS. How much swap do you have, and does the same thing happen if you reduce the Java heap and permgen space? - Peter Despite later posts, I'm leaning towards agreeing with the above, based on the information provided. N.B. Maximum heap size does not equal the maximum memory a JVM can/will use. The Perm generation is in addition to the heap so you're effectively saying that the memory you want to use is 2400 + 512 (+ other stuff falling into the non-heap category). So you may be using more than 3Gb; jmap -heap pid will provide more information, you could regularly dump the output to file to see what's happening with the JVM. http://java.sun.com/javase/6/docs/technotes/guides/management/jconsole.html (Confession: I'm not sure I've got my head round it yet) An OOM should leave a trace somewhere on your system, it might be a single log entry saying that a given process id has been terminated. Google for specific info for your OS. p - 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 - To unsubscribe, e-mail:
Re: JVM goes away
One more reason why we use this much memory: we run 2-4 contexts most of the time. This was originally done to separate certain customer data while keeping the code base the same and to allow us to have a test environment exactly like the production environment. If each context requires 50-60MB for perm gen, then the Tomcat perm gen is upwards of 256MB. Also, if each context requires 200-300MB of heap, then we could require upwards heap of 500-700MB (allowing for GC, timing, etc.) I have probably allocated more heap memory than needed (due to my faulty understanding that the heap constrained perm gen, etc.) Thanks, Carl - Original Message - From: Pid p...@pidster.com To: Carl c...@etrak-plus.com Sent: Tuesday, January 12, 2010 4:41 AM Subject: Re: JVM goes away On 12/01/2010 01:30, Carl wrote: Aha, for some reason, I thought perm gen was included in the general heap so the maximum for the two combined was constrained by the 2400m I had defined for the heap. Somewhere around 2:00AM (I am US east coast), I can restart the server with the new settings. I have taken several heap dumps (using Visual JVM) and nothing looked odd. Also, I can see (from Visual JVM) that the GC runs reasonably frequently when the heap grows (from users working) but the total heap is generally under 1GB. I wonder if the sneaky little bugger, under load, just pushes to OOM and I am running so close to the edge that I don't see it. Odd though, I have forced OOM issues in the past and they always showed up in catalina.out. Does your app actually need all that memory? p Thanks for your thoughts and help. Carl - Original Message - From: Pid p...@pidster.com To: users@tomcat.apache.org Sent: Monday, January 11, 2010 8:07 PM Subject: Re: JVM goes away On 11/01/2010 23:06, Peter Crowther wrote: 2010/1/11 Carlc...@etrak-plus.com: This is a new server, a Dell T110 with a Xeon 3440 processor and 4GB memory. I have turned off both the turbo mode and hyperthreading. The environment: 64 bit Slackware Linux java version 1.6.0_17 Java(TM) SE Runtime Environment (build 1.6.0_17-b04) Java HotSpot(TM) 64-Bit Server VM (build 14.3-b01, mixed mode) Tomcat: apache-tomcat-6.0.20 JAVA_OPTS=-Xms2400m -Xmx2400m -XX:PermSize=512m -XX:MaxPermSize=512m I have watched observed the memory usage and general performance with Java VisualVM and have seen nothing strange. GC seems to be performing well and the memory rarely gets anywhere near the max. The server runs well, idling along at 2-5% load, serving jsp's, etc. at a reasonable speed. Without warning and with no tracks in any log (Tomcat or system) or to the console, the JVM will just go away, disappear. Sometimes, the system will run for a week, sometimes for only several hours. Initially, I thought the problem was the turbo or hyperthreading but, no, the problem persists. When the JVM goes away, the memory that it held is still being held (as seen from top) but it is nowhere near the machine physical memory. The application has been running on an older server (Dell 600SC, 32 bit Slackware, 2GB memory) for several years and, while the application will throw exceptions now and then, it never crashed the JVM. This leads me to believe the problem has something to do with the 64 bit JVM but, with errors, I can't be certain and don't know what I can do about it except go back to 32 bit. I plan to reinstall Java tonight but, it would seem if the JVM were corrupted, it simply would not run. Any ideas are welcome. I'm with Andy: the Linux OOM killer would show those symptoms. With those settings, you're not leaving a lot of memory for the OS. How much swap do you have, and does the same thing happen if you reduce the Java heap and permgen space? - Peter Despite later posts, I'm leaning towards agreeing with the above, based on the information provided. N.B. Maximum heap size does not equal the maximum memory a JVM can/will use. The Perm generation is in addition to the heap so you're effectively saying that the memory you want to use is 2400 + 512 (+ other stuff falling into the non-heap category). So you may be using more than 3Gb; jmap -heap pid will provide more information, you could regularly dump the output to file to see what's happening with the JVM. http://java.sun.com/javase/6/docs/technotes/guides/management/jconsole.html (Confession: I'm not sure I've got my head round it yet) An OOM should leave a trace somewhere on your system, it might be a single log entry saying that a given process id has been terminated. Google for specific info for your OS. p - 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:
Problem publishing application.
Hi, i'm developing an application, and i'm having some problems with the publishing of it. When i deploy it my local server it works fine, with no error. But when i deploy it in other remote tomcat, it doesn't work, and it shows me the following error: org.apache.jasper.JasperException: Ha sucedido una excepción al procesar la página JSP /index.jsp en línea 2 1: %@ page % 2: jsp:forward page=/DH/ Stacktrace: org.apache.jasper.servlet.JspServletWrapper.handleJspException(JspServletWrapper.java:505) org.apache.jasper.servlet.JspServletWrapper.service(JspServletWrapper.java:398) org.apache.jasper.servlet.JspServlet.serviceJspFile(JspServlet.java:342) org.apache.jasper.servlet.JspServlet.service(JspServlet.java:267) javax.servlet.http.HttpServlet.service(HttpServlet.java:717) org.morfeo.mymw.devmgt.MultiChannelFilter.doFilter(MultiChannelFilter.java:214) *causa raíz* javax.servlet.ServletException: Configuration of DriverHTTP Failed org.morfeo.mymw.server.DriverHTTP.init(DriverHTTP.java:222) javax.servlet.GenericServlet.init(GenericServlet.java:212) org.apache.jasper.runtime.PageContextImpl.doForward(PageContextImpl.java:706) org.apache.jasper.runtime.PageContextImpl.forward(PageContextImpl.java:677) org.apache.jsp.index_jsp._jspService(index_jsp.java:56) org.apache.jasper.runtime.HttpJspBase.service(HttpJspBase.java:70) javax.servlet.http.HttpServlet.service(HttpServlet.java:717) org.apache.jasper.servlet.JspServletWrapper.service(JspServletWrapper.java:374) org.apache.jasper.servlet.JspServlet.serviceJspFile(JspServlet.java:342) org.apache.jasper.servlet.JspServlet.service(JspServlet.java:267) javax.servlet.http.HttpServlet.service(HttpServlet.java:717) org.morfeo.mymw.devmgt.MultiChannelFilter.doFilter(MultiChannelFilter.java:214) *causa raíz* javax.xml.transform.TransformerFactoryConfigurationError: Provider net.sf.saxon.TransformerFactoryImpl not found javax.xml.transform.TransformerFactory.newInstance(TransformerFactory.java:108) org.morfeo.mymw.server.flow.scxml.SCXMLFlowEngine.applyTransformations(SCXMLFlowEngine.java:428) org.morfeo.mymw.server.flow.scxml.SCXMLFlowEngine.init(SCXMLFlowEngine.java:181) sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method) sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:39) sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:27) java.lang.reflect.Constructor.newInstance(Constructor.java:513) java.lang.Class.newInstance0(Class.java:355) java.lang.Class.newInstance(Class.java:308) org.morfeo.mymw.server.AbstractAdapter.setupFlowEngine(AbstractAdapter.java:288) org.morfeo.mymw.server.AbstractAdapter.setConfiguration(AbstractAdapter.java:103) org.morfeo.mymw.server.lc.LightMobilityAdapter.setConfiguration(LightMobilityAdapter.java:143) org.morfeo.mymw.server.MobilityAdapter.setupadapterAdapter(MobilityAdapter.java:521) org.morfeo.mymw.server.MobilityAdapter.setConfiguration(MobilityAdapter.java:449) org.morfeo.mymw.server.DriverHTTP.init(DriverHTTP.java:203) javax.servlet.GenericServlet.init(GenericServlet.java:212) org.apache.jasper.runtime.PageContextImpl.doForward(PageContextImpl.java:706) org.apache.jasper.runtime.PageContextImpl.forward(PageContextImpl.java:677) org.apache.jsp.index_jsp._jspService(index_jsp.java:56) org.apache.jasper.runtime.HttpJspBase.service(HttpJspBase.java:70) javax.servlet.http.HttpServlet.service(HttpServlet.java:717) org.apache.jasper.servlet.JspServletWrapper.service(JspServletWrapper.java:374) org.apache.jasper.servlet.JspServlet.serviceJspFile(JspServlet.java:342) org.apache.jasper.servlet.JspServlet.service(JspServlet.java:267) javax.servlet.http.HttpServlet.service(HttpServlet.java:717) org.morfeo.mymw.devmgt.MultiChannelFilter.doFilter(MultiChannelFilter.java:214) Both servers are exactly the same version, with the same java version and the same applications deplyed on them. The only difference is that the local one is under windows, and the remote one is under linux. Some extra data about them: Local Server: Tomcat version: Apache Tomcat/6.0.20 JVM version: 1.6.0_15-b03 SO: Windows Vista 6.0 (x86) Remote Server: Tomcat version: Apache Tomcat/6.0.20 JVM version: 1.6.0_15-b03 SO: Linux 2.6.31-14-generic (amd64) I also have to say that its only this application which doesn't work. The rest of the applications work fine in both servers. Anyone know what can be happening? Thanks in advance -- Nicanor Gutiérrez Requejo Investigador nicanor.gutier...@fundacionctic.org CTIC - Centro Tecnológico Parque
Re: if user's browser doesn't support Cookies, then where to store user's session information?
On 12/01/2010 09:00, Peter Chen wrote:
Hi, all
I am using Tomcat 5.5.26 as the Web Server. I know the session
information is stored in Cookies with the key JSESSIONID.
Only the id is stored in the cookie.
But some browsers don't support Cookies.
So my question is if user's browser doesn't support Cookies, then where
to store user's session information?
In the URL.
If you encode every URL on the page then Tomcat will determine whether
there's a cookie and it will rewrite the URL to include the parameter
jsessionid.
a href=% response.encodeURL('/path/to/page.jsp') %Link text/a
An encoded URL will look like this:
server.com/path/to/page.jsp;jsessionid=000?some=paramgoes=here
Some frameworks (e.g. Struts) provide a tag library to do this which can
make your HTML much more readable. It's not complicated to write your
own though, if you don't want to use a framework.
html:a href=/path/to/page.jspLink text/html:a
And besides session, how to store other user's state information,
because HTTP protocol is a stateless protocol?
In a database?
p
-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Problem publishing application.
On 12/01/2010 11:03, Nicanor Gutiérrez Requejo wrote: Hi, i'm developing an application, and i'm having some problems with the publishing of it. When i deploy it my local server it works fine, with no error. But when i deploy it in other remote tomcat, it doesn't work, and it shows me the following error: org.apache.jasper.JasperException: Ha sucedido una excepción al procesar la página JSP /index.jsp en línea 2 1: %@ page % 2: jsp:forward page=/DH/ This: Stacktrace: org.apache.jasper.servlet.JspServletWrapper.handleJspException(JspServletWrapper.java:505) is caused by this: *causa raíz* javax.servlet.ServletException: Configuration of DriverHTTP Failed *causa raíz* which is caused by this: javax.xml.transform.TransformerFactoryConfigurationError: Provider net.sf.saxon.TransformerFactoryImpl not found So it looks like you're missing the net.sf.saxon classes. Check you have all the required jar files in WEB-INF/lib and Tomcat/lib. p Both servers are exactly the same version, with the same java version and the same applications deplyed on them. The only difference is that the local one is under windows, and the remote one is under linux. Some extra data about them: Local Server: Tomcat version: Apache Tomcat/6.0.20 JVM version: 1.6.0_15-b03 SO: Windows Vista 6.0 (x86) Remote Server: Tomcat version: Apache Tomcat/6.0.20 JVM version: 1.6.0_15-b03 SO: Linux 2.6.31-14-generic (amd64) I also have to say that its only this application which doesn't work. The rest of the applications work fine in both servers. Anyone know what can be happening? Thanks in advance - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: How to access webapp classes from a Context/Manager implementation (jar located in in $CATALINA_HOME/lib/)
Hi Konstantin, On Mon, 2010-01-11 at 05:19 +0300, Konstantin Kolinko wrote: 2010/1/11 Martin Grotzke martin.grot...@javakaffee.de: On Mon, 2010-01-11 at 02:54 +0300, Konstantin Kolinko wrote: 2010/1/10 Martin Grotzke martin.grot...@javakaffee.de: Hi, Jan 10, 2010 2:57:51 PM org.apache.catalina.connector.CoyoteAdapter service SEVERE: An exception or error occurred in the container during the request processing java.lang.NoClassDefFoundError: org/joda/time/format/ISODateTimeFormat at de.javakaffee.web.msm.serializer.javolution.JodaDateTimeFormat.clinit(JodaDateTimeFormat.java:35) at java.lang.Class.forName0(Native Method) at java.lang.Class.forName(Class.java:247) So, JodaDateTimeFormat was found and its clinit was called, but ISODateTimeFormat was not. JodaDateTimeFormat is the joda DateTime serializer shipped with the memcached-session-manager (msm), which should be used/activated if joda is available in the webapp classpath. ISODateTimeFormat is a class provided by joda. Where have you placed your joda jar? The joda jar is placed in WEB-INF/lib of the application. I don't want to have this in $CATALINA_HOME/lib as joda serialization shall only be supported if it's required by the webapp. The JodaDateTimeFormat comes with the msm jar located in tomcat's lib. That won't work. A class loaded from Common classloader cannot depend on classes that are in the Webapp classloader. Place them in the same place: either both in WEB-INF/lib, or both in $CATALINA_HOME/lib Thanx for this simple description, now I got it. A very simple test with my JodaDateTimeFormat placed in WEB-INF/lib is working - looks good! You may learn how java.lang.Class.forName() is called by the VM to load dependent classes, but there is a simple concern, that should be understandable: - when a web application is stopped (undeployed), all its assets have to be removed from memory. - webapp classloader belongs to the application, and takes some steps to destroy itself, when the application is stopped - classloader knows, what classes it has already loaded Simple, makes sense. When JodaDateTimeFormat class belongs to the Common classloader, it will be loaded in memory as long as Tomcat is running, and thus cannot depend on classes in the Webapp which are relatively short-lived. Implementation-wise that is class loader delegation model. The Webapp classloader is not a parent of the Common one. Reading docs again now with your explanation and the delegation model in mind I'd say that it's already in the docs :) Thanx for your help, cheers, Martin Also please read http://tomcat.apache.org/tomcat-6.0-doc/class-loader-howto.html I've already done that, but I didn't find the information to solve this issue. Also reading again didn't help ;-) Thanx cheers, Martin Best regards, Konstantin Kolinko - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org signature.asc Description: This is a digitally signed message part
RE: Tips on tracking down memory leaks
Greg, you've just awakened a 900 lb gorilla! My guess, based upon your description of the problem as large chunks at a time, is something related to reading and caching data, and this is why PMD and profiling tools won't help. Therefore, look at all the code accessing data from whatever storage you use (DB, File?), and find out where that data flows. I'd also guess is that someone is storing data in the context, maybe as a cache, or just because they don't know any better. So search for setAttribute calls in the code and trace the associated object. If that object points to the servlet context, then mark it as a candidate. This could be complicated by JSPs (if you are using them), because they could be storing data within the application scope within JSP pages (very bad practice, but very widely used). Also check out tag libraries, because it can be done there too. Check your session timeout to make sure it isn't too high (however, you did say it isn't slow growth, but check anyway). However, we could literally guess all day long, as there are dozens of ways code can eat up memory. Joe -Original Message- From: Greg McCane [mailto:gregmcc...@yahoo.ca] Sent: Monday, January 11, 2010 8:33 PM To: users@tomcat.apache.org Subject: Tips on tracking down memory leaks Hi Everyone, I am running tomcat 5.5 on Debian Linux (uname says Linux 2.6.26-2-amd64, /etc/debian_version says 5.0.2). The JVM version is 1.5.0_14-b03. We have 9 servlets running. The tomcat process itself is managed by monit. We see tomcat memory usage growing over time and have set monit to automatically restart it (using the /etc/init.d/tomcat5.5 startup script) when memory usage reaches 2.8 GB. It takes about 20 hours to get to this point. This is an attempt to avoid a tomcat crash/hang resulting in an outage for our users. The memory growth appears to be in large chunks rather than slow, steady growth. We have turned on incremental garbage collection with the following options: -XX:+UseConcMarkSweepGC -XX:+CMSIncrementalMode -XX:+CMSIncrementalPacing -XX:CMSIncrementalDutyCycleMin=0 -XX:+CMSIncrementalDutyCycle=10 -XX:-TraceClassUnloading -XX:+CMSPermGenSweepingEnabled -XX:+CMSClassUnloadingEnabled The JVM heap size is set with: -Xmx3072M -Xms1024M We have checked our code using pmd and have profiled it using TPT and Eclipse in our development environment. We have made improvements as a result of the findings from these tools, but we are still having problems. Any suggestions for next steps to help us get to the root cause of this problem? Thanks, Greg __ Looking for the perfect gift? Give the gift of Flickr! http://www.flickr.com/gift/ - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
RE: Exception in localhost file
Jan 11, 2010 4:12:57 PM org.apache.catalina.core.StandardWrapperValve invoke SEVERE: Servlet.service() for servlet SwchServlet threw exception java.lang.ArrayIndexOutOfBoundsException There is no clue as to why this might be happening. False, that IS the clue. SwchServlet code is using an index into an array (or something ultimately treated as an array) and simply stepping outside the bounds. Is the code using a logger? Check how that is used/configured, as that might be why you're not seeing a full stack trace. Someone may have written code to trap an exception and then issue their own message. -Original Message- From: Mohit Anchlia [mailto:mohitanch...@gmail.com] Sent: Monday, January 11, 2010 8:10 PM To: Tomcat Users List Subject: Exception in localhost file tomcat 6: I am seeing following exception in localhost file with no stack trace. There is no clue as to why this might be happening. How do I get the full stack trace to narrow down the problem? We also have our application log where our application specific exceptions get logged with full stack trace but this is not being logged there. Jan 11, 2010 4:12:57 PM org.apache.catalina.core.StandardWrapperValve invoke SEVERE: Servlet.service() for servlet SwchServlet threw exception java.lang.ArrayIndexOutOfBoundsException - 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: Tips on tracking down memory leaks
From: Greg McCane [mailto:gregmcc...@yahoo.ca] Subject: Tips on tracking down memory leaks The memory growth appears to be in large chunks rather than slow, steady growth. Use a heap profiler to find out what's eating up the space and who is allocating it. Even the simple one (hprof) included in the 1.5 JDK will tell you that. Better ones (e.g., jhat) are available in 1.6, if you're willing to move up. There are also numerous 3rd-party profilers available, with YourKit being a favorite of many. - 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: Problem publishing application.
Solved, thanks for your help. The linux server needed the saxon's jars. Don't know exactly why the applications works in Windows without them, maybe they are in the classpath or something similar that i can't find. So thanks again. Pid escribió: On 12/01/2010 11:03, Nicanor Gutiérrez Requejo wrote: Hi, i'm developing an application, and i'm having some problems with the publishing of it. When i deploy it my local server it works fine, with no error. But when i deploy it in other remote tomcat, it doesn't work, and it shows me the following error: org.apache.jasper.JasperException: Ha sucedido una excepción al procesar la página JSP /index.jsp en línea 2 1: %@ page % 2: jsp:forward page=/DH/ This: Stacktrace: org.apache.jasper.servlet.JspServletWrapper.handleJspException(JspServletWrapper.java:505) is caused by this: *causa raíz* javax.servlet.ServletException: Configuration of DriverHTTP Failed *causa raíz* which is caused by this: javax.xml.transform.TransformerFactoryConfigurationError: Provider net.sf.saxon.TransformerFactoryImpl not found So it looks like you're missing the net.sf.saxon classes. Check you have all the required jar files in WEB-INF/lib and Tomcat/lib. p Both servers are exactly the same version, with the same java version and the same applications deplyed on them. The only difference is that the local one is under windows, and the remote one is under linux. Some extra data about them: Local Server: Tomcat version: Apache Tomcat/6.0.20 JVM version: 1.6.0_15-b03 SO: Windows Vista 6.0 (x86) Remote Server: Tomcat version: Apache Tomcat/6.0.20 JVM version: 1.6.0_15-b03 SO: Linux 2.6.31-14-generic (amd64) I also have to say that its only this application which doesn't work. The rest of the applications work fine in both servers. Anyone know what can be happening? Thanks in advance - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org -- Nicanor Gutiérrez Requejo Investigador CTIC-Centro Tecnológico c/ Ada Byron, 39 Edificio Centros Tecnológicos 33203 Gijón - Asturias - España Tel.: +34 984 29 12 12 Fax: +34 984 39 06 12 E-mail: nicanor.gutier...@fundacionctic.org http://www.fundacionctic.org Política de Privacidad: http://www.fundacionctic.org/privacidad - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Polling and session timeout
I have a GWT application that polls tomcat periodically to deliver notifications into the browser. This works well, except that the session never times out since the poll period is much shorter than our tomcat timeout (have set to 15 minutes now). Is there any way to specify that my PollingServlet does not cause a reset of the session timeout. Or to have the PollingServlet use a different, perhaps transient, session? Thanks for your help. Michael -- View this message in context: http://old.nabble.com/Polling-and-session-timeout-tp27129549p27129549.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: Exception in localhost file
There seems to be no code. This is logging properties. I am not sure why the exception is not getting logged. I do have application specific log4j.xml but that's only for application logs that is working fine. #org.apache.catalina.core.ContainerBase.[Catalina].[localhost].level = INFO org.apache.catalina.core.ContainerBase.[Catalina].[localhost].level = INFO org.apache.catalina.core.ContainerBase.[Catalina].[localhost].handlers = 2localhost.org.apache.juli.FileHandler org.apache.catalina.core.ContainerBase.[Catalina].[localhost].[/manager].level = INFO org.apache.catalina.core.ContainerBase.[Catalina].[localhost].[/manager].handlers = 3manager.org.apache.juli.FileHandler org.apache.catalina.core.ContainerBase.[Catalina].[localhost].[/admin].level = INFO org.apache.catalina.core.ContainerBase.[Catalina].[localhost].[/admin].handlers = 4admin.org.apache.juli.FileHandler org.apache.catalina.core.ContainerBase.[Catalina].[localhost].[/host-manager].level = INFO org.apache.catalina.core.ContainerBase.[Catalina].[localhost].[/host-manager].handlers = 5host-manager.org.apache.juli.FileHandler On Tue, Jan 12, 2010 at 5:29 AM, Joseph Morgan joseph.mor...@ignitesales.com wrote: Jan 11, 2010 4:12:57 PM org.apache.catalina.core.StandardWrapperValve invoke SEVERE: Servlet.service() for servlet SwchServlet threw exception java.lang.ArrayIndexOutOfBoundsException There is no clue as to why this might be happening. False, that IS the clue. SwchServlet code is using an index into an array (or something ultimately treated as an array) and simply stepping outside the bounds. Is the code using a logger? Check how that is used/configured, as that might be why you're not seeing a full stack trace. Someone may have written code to trap an exception and then issue their own message. -Original Message- From: Mohit Anchlia [mailto:mohitanch...@gmail.com] Sent: Monday, January 11, 2010 8:10 PM To: Tomcat Users List Subject: Exception in localhost file tomcat 6: I am seeing following exception in localhost file with no stack trace. There is no clue as to why this might be happening. How do I get the full stack trace to narrow down the problem? We also have our application log where our application specific exceptions get logged with full stack trace but this is not being logged there. Jan 11, 2010 4:12:57 PM org.apache.catalina.core.StandardWrapperValve invoke SEVERE: Servlet.service() for servlet SwchServlet threw exception java.lang.ArrayIndexOutOfBoundsException - 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 - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
RE: Exception in localhost file
This isn't a Tomcat issue at all, just code in SwchServlet behaving badly or getting unexpected data. -Original Message- From: Mohit Anchlia [mailto:mohitanch...@gmail.com] Sent: Tuesday, January 12, 2010 9:58 AM To: Tomcat Users List Subject: Re: Exception in localhost file There seems to be no code. This is logging properties. I am not sure why the exception is not getting logged. I do have application specific log4j.xml but that's only for application logs that is working fine. #org.apache.catalina.core.ContainerBase.[Catalina].[localhost].level = INFO org.apache.catalina.core.ContainerBase.[Catalina].[localhost].level = INFO org.apache.catalina.core.ContainerBase.[Catalina].[localhost].handlers = 2localhost.org.apache.juli.FileHandler org.apache.catalina.core.ContainerBase.[Catalina].[localhost].[/manager].level = INFO org.apache.catalina.core.ContainerBase.[Catalina].[localhost].[/manager].handlers = 3manager.org.apache.juli.FileHandler org.apache.catalina.core.ContainerBase.[Catalina].[localhost].[/admin].level = INFO org.apache.catalina.core.ContainerBase.[Catalina].[localhost].[/admin].handlers = 4admin.org.apache.juli.FileHandler org.apache.catalina.core.ContainerBase.[Catalina].[localhost].[/host-manager].level = INFO org.apache.catalina.core.ContainerBase.[Catalina].[localhost].[/host-manager].handlers = 5host-manager.org.apache.juli.FileHandler On Tue, Jan 12, 2010 at 5:29 AM, Joseph Morgan joseph.mor...@ignitesales.com wrote: Jan 11, 2010 4:12:57 PM org.apache.catalina.core.StandardWrapperValve invoke SEVERE: Servlet.service() for servlet SwchServlet threw exception java.lang.ArrayIndexOutOfBoundsException There is no clue as to why this might be happening. False, that IS the clue. SwchServlet code is using an index into an array (or something ultimately treated as an array) and simply stepping outside the bounds. Is the code using a logger? Check how that is used/configured, as that might be why you're not seeing a full stack trace. Someone may have written code to trap an exception and then issue their own message. -Original Message- From: Mohit Anchlia [mailto:mohitanch...@gmail.com] Sent: Monday, January 11, 2010 8:10 PM To: Tomcat Users List Subject: Exception in localhost file tomcat 6: I am seeing following exception in localhost file with no stack trace. There is no clue as to why this might be happening. How do I get the full stack trace to narrow down the problem? We also have our application log where our application specific exceptions get logged with full stack trace but this is not being logged there. Jan 11, 2010 4:12:57 PM org.apache.catalina.core.StandardWrapperValve invoke SEVERE: Servlet.service() for servlet SwchServlet threw exception java.lang.ArrayIndexOutOfBoundsException - 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 - 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: Exception in localhost file
From: Mohit Anchlia [mailto:mohitanch...@gmail.com] Subject: Re: Exception in localhost file There seems to be no code. Obviously a false statement. You need to find the code for SwchServlet (it's not part of Tomcat) and determine why it is throwing (and possibly swallowing) the exception. I do have application specific log4j.xml but that's only for application logs that is working fine. No, your log4j will be handling this logging as well, so it's not working fine. - 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: Exception in localhost file
Yes. I understand that. I was trying to understand why full stack trace is not being logged in localhost On Tue, Jan 12, 2010 at 8:11 AM, Joseph Morgan joseph.mor...@ignitesales.com wrote: This isn't a Tomcat issue at all, just code in SwchServlet behaving badly or getting unexpected data. -Original Message- From: Mohit Anchlia [mailto:mohitanch...@gmail.com] Sent: Tuesday, January 12, 2010 9:58 AM To: Tomcat Users List Subject: Re: Exception in localhost file There seems to be no code. This is logging properties. I am not sure why the exception is not getting logged. I do have application specific log4j.xml but that's only for application logs that is working fine. #org.apache.catalina.core.ContainerBase.[Catalina].[localhost].level = INFO org.apache.catalina.core.ContainerBase.[Catalina].[localhost].level = INFO org.apache.catalina.core.ContainerBase.[Catalina].[localhost].handlers = 2localhost.org.apache.juli.FileHandler org.apache.catalina.core.ContainerBase.[Catalina].[localhost].[/manager].level = INFO org.apache.catalina.core.ContainerBase.[Catalina].[localhost].[/manager].handlers = 3manager.org.apache.juli.FileHandler org.apache.catalina.core.ContainerBase.[Catalina].[localhost].[/admin].level = INFO org.apache.catalina.core.ContainerBase.[Catalina].[localhost].[/admin].handlers = 4admin.org.apache.juli.FileHandler org.apache.catalina.core.ContainerBase.[Catalina].[localhost].[/host-manager].level = INFO org.apache.catalina.core.ContainerBase.[Catalina].[localhost].[/host-manager].handlers = 5host-manager.org.apache.juli.FileHandler On Tue, Jan 12, 2010 at 5:29 AM, Joseph Morgan joseph.mor...@ignitesales.com wrote: Jan 11, 2010 4:12:57 PM org.apache.catalina.core.StandardWrapperValve invoke SEVERE: Servlet.service() for servlet SwchServlet threw exception java.lang.ArrayIndexOutOfBoundsException There is no clue as to why this might be happening. False, that IS the clue. SwchServlet code is using an index into an array (or something ultimately treated as an array) and simply stepping outside the bounds. Is the code using a logger? Check how that is used/configured, as that might be why you're not seeing a full stack trace. Someone may have written code to trap an exception and then issue their own message. -Original Message- From: Mohit Anchlia [mailto:mohitanch...@gmail.com] Sent: Monday, January 11, 2010 8:10 PM To: Tomcat Users List Subject: Exception in localhost file tomcat 6: I am seeing following exception in localhost file with no stack trace. There is no clue as to why this might be happening. How do I get the full stack trace to narrow down the problem? We also have our application log where our application specific exceptions get logged with full stack trace but this is not being logged there. Jan 11, 2010 4:12:57 PM org.apache.catalina.core.StandardWrapperValve invoke SEVERE: Servlet.service() for servlet SwchServlet threw exception java.lang.ArrayIndexOutOfBoundsException - 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 - 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 - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Client authentication problems
Dear tomcat users, I run tomcat 6.0.18 under java 6 and am attempting to set up client authentication via SSL. I have followed the instructions here: http://tomcat.apache.org/tomcat-6.0-doc/ssl-howto.html, with Tomcat using the default SSL implementation. We act as our own CA, so I have set up java keystores at both server and client, each of which has the same CA certificate, but a distinct actual certificate. I am attempting to test using HttpClient as described here: http://hc.apache.org/httpclient-3.x/sslguide.html and am using AuthSSLProtocolSocketFactory. The client gets hold of the server certificates OK but then the test fails with the error : Fatal transport error: Received fatal alert: certificate_unknown javax.net.ssl.SSLHandshakeException: Received fatal alert: certificate_unknown at com.sun.net.ssl.internal.ssl.Alerts.getSSLException(Unknown Source) at com.sun.net.ssl.internal.ssl.Alerts.getSSLException(Unknown Source) at com.sun.net.ssl.internal.ssl.SSLSocketImpl.recvAlert(Unknown Source). I see no sign of any logging of the SSL handshake at the server side. If I switch off client authentication (in server.xml) at the server, everything's fine. Similarly, if I actually use the keystore that contains the server certs at the client side, all's OK too. I'd appreciate any help you can give - particularly if you can help me log the SSL handshake at the server to try to figure out what's happening. Cheers John Watson ** Satellite Information Services Limited. Registered Office: 17 Corsham Street, London, N1 6DR. Company No. 4243307 The information in this email (which includes any files transmitted with it) is confidential and is intended for the addressee only. Unauthorized recipients are required to maintain confidentiality. If you have received this email in error please notify the sender immediately, destroy any copies and delete it from your computer system. **
RE: Running Tomcat 6 as a service
I commented out those lines, I changed the startmode and stopmode to exe (and also tried java). I get an error when starting the service. I checked all of the paths and they appear to be correct. The error that I am getting is: [2010-01-12 10:40:39] [info] Procrun (2.0.4.0) started [2010-01-12 10:40:39] [info] Running Service... [2010-01-12 10:40:39] [info] Starting service... [2010-01-12 10:40:39] [1030 prunsrv.c] [error] Failed setting process executable [2010-01-12 10:40:39] [1269 prunsrv.c] [error] ServiceStart returned 2 [2010-01-12 10:40:39] [info] Run service finished. [2010-01-12 10:40:39] [info] Procrun finished. Does anyone know how I can correct that?? -Original Message- From: Pid [mailto:p...@pidster.com] Sent: Tuesday, January 12, 2010 3:44 AM To: users@tomcat.apache.org Subject: Re: Running Tomcat 6 as a service On 12/01/2010 04:10, Russell Collins wrote: I am using JRockit as my java runtime. When I manually start Tomcat, I have no problems with it. However, when I try to run Tomcat as a service with JRockit as my java runtime, I get an error that says that it cannot start the service. I looked in the service.bat file and I think that I may have found where this error is happening. The following lines are in the batch file rem Set the server jvm from JAVA_HOME set PR_JVM=%JAVA_HOME%\jre\bin\server\jvm.dll if exist %PR_JVM% goto foundJvm rem Set the client jvm from JAVA_HOME set PR_JVM=%JAVA_HOME%\jre\bin\client\jvm.dll if exist %PR_JVM% goto foundJvm JRockit does not have these entries in their java runtime directories. These are specific to Sun's implementation. The interesting thing is that I also run an Apache Geronimo serice using JRockit as the java runtime and it runs great. Can these lines be omitted? Are they crucial for Apache Tomcat to run as a service without issue? Do or do not, there is no try. - Yoda Maybe you could try it? p CONFIDENTIALITY NOTICE: The information contained in this electronic mail (email) transmission (including attachments), is intended by MCLANE ADVANCED TECHNOLOGIES for the use of the named individual or entity to which it is addressed and may contain information that is privileged, confidential and/or protected as a trade secret. It is not intended for transmission to, or receipt by, any individual or entity other than the named addressee(s). If you have received this email in error, please delete it (including attachments) and any copies thereof without printing, copying or forwarding it, and notify the sender of the error by email reply immediately. - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org CONFIDENTIALITY NOTICE: The information contained in this electronic mail (email) transmission (including attachments), is intended by MCLANE ADVANCED TECHNOLOGIES for the use of the named individual or entity to which it is addressed and may contain information that is privileged, confidential and/or protected as a trade secret. It is not intended for transmission to, or receipt by, any individual or entity other than the named addressee(s). If you have received this email in error, please delete it (including attachments) and any copies thereof without printing, copying or forwarding it, and notify the sender of the error by email reply immediately. - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
More on Tomcat Sessions - limiting cluster session replication to sessions that will last longer than 'n' duration
Earlier this week I posted a question about how to prevent sessions from being created in our Tapestry pages, and/or how to get Tomcat to get rid of a bunch of '1-second' sessions we're creating during a load test because the sessions eventually fill up the heap. (They are being created faster than Tomcat can clean them out - even though they expire faster than we create them.) So, my lead developer thinks he has found a way to alleviate our problems (at least for our production Tomcat 6.0.20 cluster of 4 servers). We will not replicate sessions to other cluster members unless they have a duration longer than a 'threshold' we set. We are altering the DeltaManager to make this change, so that simply creating a session doesn't automatically guarantee that it is replicated to other nodes in the cluster. The session duration will also have to be greater than a sessionDurationMinThreshold value we will set in the 'server.xml' file for the new DeltaManager. The idea is that sessions created that have very short durations are really 'transient' anyway, so there is no need to pass them off to the other members of the cluster. The question I have, is there anything we should watch out for in making this adjustment to the DeltaManager? We will test this pretty heavily before we deploy it to our production environment, but I'm worried about things we should be looking for in that testing (other than just validating that our useful session data can be available across multiple cluster members). -- Robin D. Wilson Director of Web Development KingsIsle Entertainment, Inc. CELL: 512-426-3929 DESK: 512-623-5913 www.KingsIsle.com - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: More on Tomcat Sessions - limiting cluster session replication to sessions that will last longer than 'n' duration
On 12/01/2010 16:47, Robin Wilson wrote: Earlier this week I posted a question about how to prevent sessions from being created in our Tapestry pages, and/or how to get Tomcat to get rid of a bunch of '1-second' sessions we're creating during a load test because the sessions eventually fill up the heap. (They are being created faster than Tomcat can clean them out - even though they expire faster than we create them.) So, my lead developer thinks he has found a way to alleviate our problems (at least for our production Tomcat 6.0.20 cluster of 4 servers). We will not replicate sessions to other cluster members unless they have a duration longer than a 'threshold' we set. We are altering the DeltaManager to make this change, so that simply creating a session doesn't automatically guarantee that it is replicated to other nodes in the cluster. The session duration will also have to be greater than a sessionDurationMinThreshold value we will set in the 'server.xml' file for the new DeltaManager. The idea is that sessions created that have very short durations are really 'transient' anyway, so there is no need to pass them off to the other members of the cluster. The question I have, is there anything we should watch out for in making this adjustment to the DeltaManager? We will test this pretty heavily before we deploy it to our production environment, but I'm worried about things we should be looking for in that testing (other than just validating that our useful session data can be available across multiple cluster members). Robin, please post a new message when starting a new thread. When you reply, even if you edit the subject line content, the In-Reply-To header is still set so, in a threaded email view you have responded to a different thread. (See Thread-hijacking.) p -- Robin D. Wilson Director of Web Development KingsIsle Entertainment, Inc. CELL: 512-426-3929 DESK: 512-623-5913 www.KingsIsle.com - 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
More on Tomcat Sessions - limiting cluster session replication to sessions that will last longer than 'n' duration
REPOSTING this so it won't be on the other thread - sorry about that. Earlier this week I posted a question about how to prevent sessions from being created in our Tapestry pages, and/or how to get Tomcat to get rid of a bunch of '1-second' sessions we're creating during a load test because the sessions eventually fill up the heap. (They are being created faster than Tomcat can clean them out - even though they expire faster than we create them.) So, my lead developer thinks he has found a way to alleviate our problems (at least for our production Tomcat 6.0.20 cluster of 4 servers). We will not replicate sessions to other cluster members unless they have a duration longer than a 'threshold' we set. We are altering the DeltaManager to make this change, so that simply creating a session doesn't automatically guarantee that it is replicated to other nodes in the cluster. The session duration will also have to be greater than a sessionDurationMinThreshold value we will set in the 'server.xml' file for the new DeltaManager. The idea is that sessions created that have very short durations are really 'transient' anyway, so there is no need to pass them off to the other members of the cluster. The question I have, is there anything we should watch out for in making this adjustment to the DeltaManager? We will test this pretty heavily before we deploy it to our production environment, but I'm worried about things we should be looking for in that testing (other than just validating that our useful session data can be available across multiple cluster members). -- Robin D. Wilson Director of Web Development KingsIsle Entertainment, Inc. CELL: 512-426-3929 DESK: 512-623-5913 www.KingsIsle.com - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Tomcat Filter Mapping Issue
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Patrick, On 1/10/2010 1:45 PM, Patrick Flaherty wrote: I do not dispute you at all, don't get me wrong. It's even been proven in my testing that this is what made filter mapping work for me. If you have a link that illustrates this I would appreciate you sharing it. Then I can rest knowing this is how we should have been doing it from day one. I think one of the things that is clouding the issue is Tomcat's desire to automatically deploy anything that looks like it might be a webapp. For instance, if you have a Host with appBase=c:\app1, where c:\app1 looks like this: WEB-INF/web.xml Proofs/ [whatever] ...then what Tomcat does is treat WEB-INF as a web application and deploys it under the /WEB-INF URL path (it's possible that Tomcat explicitly checks for this insane configuration and avoids exposing /META-INF, so this claim may not be entirely correct). Tomcat will definitely deploy the Proofs directory under /Proofs. Since c:\app1\Proofs does not have a WEB-INF/web.xml, it gets the default deployment descriptor, which is basically just *.jsp maps to the JSP Servlet and everything else will get served using the DefaultServlet, which just serves files directly just like a standard web server. In this situation, c:\app1 appears to work like a traditional web server's document root for the Host. Then, you added a filter mapping under C:\app1\WEB-INF\web.xml and it didn't work: that's because /Proofs was a different web application and the web.xml file you modified had nothing to do with the Proofs webapp that Tomcat deployed for you. Moving everything into c:\app1\ROOT mounts the whole shebang on /, which is what you had expected all along. As to your questions about multiple webapps and URL prefixes: If you want to deploy several webapps, they must each have a separate context and separate top-level URL mapping (like, app1 is on ROOT (or /), app2 is under /app2, app3 is under /app3, etc.). There is no way to deploy multiple webapps to a single context. One solution would be to merge the webapps into a single webapp and deploy it once, most likely as ROOT. Another possibility is to create a ROOT webapp that gives the visitor a menu of options that allows them to pick their webapp without having to remember the URL mapping (say /app2). Not only is this all explicitly defined in the Java Servlet Specification, it's the only thing that makes any sense at all. If you feel like you have a reasonable use case for deploying multiple webapps into a single URL space, I'd love to hear it. I suspect that any scenario you describe can be easily configured in a sane way... as long as you are thinking about webapps and deployments correctly. - -chris -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAktM3NgACgkQ9CaO5/Lv0PBKOgCgnF60uonFMrSodcp1zCrto1x4 G0oAoJlmWTcplSyTn5Sm5xS6fd8WVwcD =wJde -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: mod_jk: plus-character causes %-encoding problems
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Tero, On 1/11/2010 8:41 AM, Tero Karttunen wrote: [snip] RedirectMatch ^/sites(.*)$ /contextroot/subcontext/sites$1 [snip] OBSERVED BEHAVIOR WITH +ForwardURIProxy: (implicit) = I try to access URL http://localhost/sites/one%2Bone%3Cthree with Internet Explorer browser. Apache HTTPD access log: 131.177.146.160 [11/Jan/2010:12:42:49 +0200] GET /sites/one%2Bone%3Cthree HTTP/1.1 +302 -(-) 263 0 131.177.146.160 [11/Jan/2010:12:42:49 +0200] GET /contextroot/subcontext/sites/one+one%3cthree HTTP/1.1 +200 worker2(worker2) 399 0 As you surmised, the RedirectMatch appears to be breaking your URI: %2B - - + instead of %2B - %2B. Notice that mod_alias has erronously (considering the use case in question) re-encoded the URL, causing %2B to change into '+' and %3C to change into equivalent %3c. Note that mod_jk is not involved, here: mod_alias is performing the redirect and mod_jk does not get involved. Also, the change from %3C to %3c is not really a problem: HTTP allows either upper or lowercase %-encoded URI elements (see section 2.2 of http://www.ietf.org/rfc/rfc1738.txt). Now, if I manually modify the address bar to access http://localhost/contextroot/subcontext/sites/one%2Bone%3Cfour, Apache HTTPD access log now shows: 131.177.146.160 [11/Jan/2010:12:53:37 +0200] GET /ts_core_virtual_repository/TeamCenterEmulator/sites/one%2Bone%3Cfour HTTP/1.1 +200 worker1(worker1) 399 15625 Good. but Tomcat access log still shows: 131.177.146.160 - - [11/Jan/2010:12:53:34 +0200] GET /ts_core_virtual_repository/TeamCenterEmulator/sites/one+one%3Cfour HTTP/1.1 200 399 Right: that's wrong. and my application sees after decoding the URL: sites/one onefour Given that Tomcat saw one+one%3Cfour, this is correct decoding. What does the mod_jk log show for this request? Quite interesting: No URL rewriting should occur at Apache HTTPD, because the RedirectMatch rule does not match, but the URLs in HTTPD and Tomcat access logs are semantically different. Well, the RedirectMatch rule does match for the first request, and it definitely appears that mod_alias is mangling your URL. Have you tried snooping the HTTP conversation to make sure it's not your web browser that is misinterpreting the 302 response from httpd? Now, I again manually modify the address bar to access http://localhost/contextroot/subcontext/sites/one%2Bone%3Csix. This time, Apache HTTPD access log shows: 131.177.146.160 [11/Jan/2010:13:00:20 +0200] GET /contextroot/subcontext/sites/one%2Bone%3csix HTTP/1.1 +200 worker1(worker1) 399 15625 and Tomcat access log shows: 131.177.146.160 - - [11/Jan/2010:13:00:18 +0200] GET /contextroot/subcontext/sites/one%2Bone%3csix HTTP/1.1 200 399 This time my application sees the intended request after decoding the URL: sites/one+onesix This all looks correct. When your web browser sends a correct URI, your webapp sees the correct URI. I would leave +ForwardURICompatUnparsed enabled for mod_jk. JkOption ForwardURICompatUnparsed seem to offer a workaround for this problem for the load balancer, but the solution has its own problems (incompability with mod_rewrite among other things, although that does not seem to apply to browser redirects). I have not found a similar workaround for mod_alias yet. You aren't using mod_rewrite, so such incompatibilities should not be a problem. How should I change my configuration so that http://localhost/sites/one%2Bone%3Cthree gives the same same results as http://localhost:8082/contextroot/subcontext/sites/one%2Bone%3Cthree? - From your observations, I would expect that this is either a bug in mod_alias (%2B - +) or in your web browser. Only reading the HTTP traffic will tell you which it is. Good luck, - -chris -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAktM4VQACgkQ9CaO5/Lv0PCdhACeIHMjqzMTxiOLC7h8fv7bnTl7 j6AAoI5h0SSglg1zfQ3588H4J8Ey8PsD =Ike1 -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: More on Tomcat Sessions - limiting cluster session replication to sessions that will last longer than 'n' duration
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Robin, On 1/12/2010 1:42 PM, Robin Wilson wrote: Earlier this week I posted a question about how to prevent sessions from being created in our Tapestry pages, and/or how to get Tomcat to get rid of a bunch of '1-second' sessions we're creating during a load test because the sessions eventually fill up the heap. (They are being created faster than Tomcat can clean them out - even though they expire faster than we create them.) Well, they are eligible for expiration faster than they are being created. That session expiration thread can't be running /all/ the time :) So, my lead developer thinks he has found a way to alleviate our problems (at least for our production Tomcat 6.0.20 cluster of 4 servers). We will not replicate sessions to other cluster members unless they have a duration longer than a 'threshold' we set. Aah... I didn't realize that you were experiencing a session replication storm in your test setup. I thought you were only using a single app server for load testing. Did I misunderstand? We are altering the DeltaManager to make this change, so that simply creating a session doesn't automatically guarantee that it is replicated to other nodes in the cluster. The session duration will also have to be greater than a sessionDurationMinThreshold value we will set in the 'server.xml' file for the new DeltaManager. The idea is that sessions created that have very short durations are really 'transient' anyway, so there is no need to pass them off to the other members of the cluster. One could argue that sessions limited to that length of time are not necessary at all. Why bother creating them in the first place? The question I have, is there anything we should watch out for in making this adjustment to the DeltaManager? We will test this pretty heavily before we deploy it to our production environment, but I'm worried about things we should be looking for in that testing (other than just validating that our useful session data can be available across multiple cluster members). Give some of the cluster gurus on the list a chance to read your question. Feel free to start your implementation: I'm guessing it's a pretty simple change to simply ignore sessions with low timeouts. Depending on how to set up your sessions, you may not be able to prevent the replication (or replication of useful sessions may not occur). I've never looked at the code for the DeltaManager, but I can imagine a scenario like this: 0. Your web.xml configures the default session timeout to be 1 second 1. Upon session creation, DeltaManager is notified that a session has been created and will need to be replicated 2. DeltaManager sees that the sessionDurationMinThreshold is only 5s, and so it decides not to replicate that session throughout the cluster 3. Your code (still during the request that created the session) determines that this will be a useful session and changes the timeout, say, to 30 minutes Result: a useful session is never replicated Conversely, the opposite situation could occur if your default timeout is 30 minutes and you intentionally reduce the timeout for sessions expected to be useless: in this case, replication occurs all the time. Beware! - -chris -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAktM5B4ACgkQ9CaO5/Lv0PDj5wCfZ4CGx2XZbq+qsFx9/GVK6eCy 6HQAoJvD81ghtJl7L9KGCvKyTXN9LF0j =2nq7 -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
RE: More on Tomcat Sessions - limiting cluster session replication to sessions that will last longer than 'n' duration
Thanks for your response, here are my answers to your questions... In our test environment, we have a 2 server cluster, but our front-end Apache server is only hitting one of them. Regardless of that fact, all sessions created on either server get replicated to the other. So as they are created on the single test path, they get replicated to the second tomcat server. With only 2 cluster members, this isn't really a big deal (except for the load generators being able to create sessions faster than Tomcat can get rid of them). However, in our production environment we have 4 cluster members, so it only takes 1/4 of the load on each server to max out all 4 servers in terms of session creation speed. Keep in mind that during this situation, the _only_ problem we're seeing is that the sessions eventually fill up the heap. Performance remains good until the heap fills up and we start thrashing on Full GCs. (Clearly, more memory will help - by extending the duration we can sustain of peak loads, but a better solution will be to stop creating sessions for stuff that doesn't need it.) Your point is well taken about not creating the short-duration sessions, but alas, Tapestry is the chosen framework - and it uses the session as a mechanism to pass (more-or-less) global values between components of the page creation process. So ripping out that capability in Tapestry would require a massive change to our infrastructure. Your notes on the clustering (changes to DeltaManager) are right on target. So we adjusted when the DeltaManager creates the session until the end of processing, so that we know the timeout before we attempt to replicate it to other cluster members. That way, we already know the actual timeout duration before we decide whether to replicate. All of this would be unnecessary if there was some sort of session cleanup process that could dump expired sessions en masse every so often. Near as we can tell, each session has to be individually expired, which is why it lags so far behind the creation process. -- Robin D. Wilson Director of Web Development KingsIsle Entertainment, Inc. CELL: 512-426-3929 DESK: 512-623-5913 www.KingsIsle.com -Original Message- From: Christopher Schultz [mailto:ch...@christopherschultz.net] Sent: Tuesday, January 12, 2010 3:06 PM To: Tomcat Users List Subject: Re: More on Tomcat Sessions - limiting cluster session replication to sessions that will last longer than 'n' duration -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Robin, On 1/12/2010 1:42 PM, Robin Wilson wrote: Earlier this week I posted a question about how to prevent sessions from being created in our Tapestry pages, and/or how to get Tomcat to get rid of a bunch of '1-second' sessions we're creating during a load test because the sessions eventually fill up the heap. (They are being created faster than Tomcat can clean them out - even though they expire faster than we create them.) Well, they are eligible for expiration faster than they are being created. That session expiration thread can't be running /all/ the time :) So, my lead developer thinks he has found a way to alleviate our problems (at least for our production Tomcat 6.0.20 cluster of 4 servers). We will not replicate sessions to other cluster members unless they have a duration longer than a 'threshold' we set. Aah... I didn't realize that you were experiencing a session replication storm in your test setup. I thought you were only using a single app server for load testing. Did I misunderstand? We are altering the DeltaManager to make this change, so that simply creating a session doesn't automatically guarantee that it is replicated to other nodes in the cluster. The session duration will also have to be greater than a sessionDurationMinThreshold value we will set in the 'server.xml' file for the new DeltaManager. The idea is that sessions created that have very short durations are really 'transient' anyway, so there is no need to pass them off to the other members of the cluster. One could argue that sessions limited to that length of time are not necessary at all. Why bother creating them in the first place? The question I have, is there anything we should watch out for in making this adjustment to the DeltaManager? We will test this pretty heavily before we deploy it to our production environment, but I'm worried about things we should be looking for in that testing (other than just validating that our useful session data can be available across multiple cluster members). Give some of the cluster gurus on the list a chance to read your question. Feel free to start your implementation: I'm guessing it's a pretty simple change to simply ignore sessions with low timeouts. Depending on how to set up your sessions, you may not be able to prevent the replication (or replication of useful sessions may not occur). I've never looked at the code for the DeltaManager, but I can imagine
Re: More on Tomcat Sessions - limiting cluster session replication to sessions that will last longer than 'n' duration
On 12/01/2010 21:05, Christopher Schultz wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Robin, On 1/12/2010 1:42 PM, Robin Wilson wrote: Earlier this week I posted a question about how to prevent sessions from being created in our Tapestry pages, and/or how to get Tomcat to get rid of a bunch of '1-second' sessions we're creating during a load test because the sessions eventually fill up the heap. (They are being created faster than Tomcat can clean them out - even though they expire faster than we create them.) Well, they are eligible for expiration faster than they are being created. That session expiration thread can't be running /all/ the time :) So, my lead developer thinks he has found a way to alleviate our problems (at least for our production Tomcat 6.0.20 cluster of 4 servers). We will not replicate sessions to other cluster members unless they have a duration longer than a 'threshold' we set. Aah... I didn't realize that you were experiencing a session replication storm in your test setup. I thought you were only using a single app server for load testing. Did I misunderstand? We are altering the DeltaManager to make this change, so that simply creating a session doesn't automatically guarantee that it is replicated to other nodes in the cluster. The session duration will also have to be greater than a sessionDurationMinThreshold value we will set in the 'server.xml' file for the new DeltaManager. The idea is that sessions created that have very short durations are really 'transient' anyway, so there is no need to pass them off to the other members of the cluster. One could argue that sessions limited to that length of time are not necessary at all. Why bother creating them in the first place? The question I have, is there anything we should watch out for in making this adjustment to the DeltaManager? We will test this pretty heavily before we deploy it to our production environment, but I'm worried about things we should be looking for in that testing (other than just validating that our useful session data can be available across multiple cluster members). Give some of the cluster gurus on the list a chance to read your question. Feel free to start your implementation: I'm guessing it's a pretty simple change to simply ignore sessions with low timeouts. Depending on how to set up your sessions, you may not be able to prevent the replication (or replication of useful sessions may not occur). I've never looked at the code for the DeltaManager, but I can imagine a scenario like this: 0. Your web.xml configures the default session timeout to be 1 second 1. Upon session creation, DeltaManager is notified that a session has been created and will need to be replicated 2. DeltaManager sees that the sessionDurationMinThreshold is only 5s, and so it decides not to replicate that session throughout the cluster 3. Your code (still during the request that created the session) determines that this will be a useful session and changes the timeout, say, to 30 minutes Result: a useful session is never replicated Conversely, the opposite situation could occur if your default timeout is 30 minutes and you intentionally reduce the timeout for sessions expected to be useless: in this case, replication occurs all the time. Beware! If you can't stop the session from being created, storing a value in the session to indicate whether the session should be replicated might be easier to manage monitor than juggling variable session times. p - -chris -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAktM5B4ACgkQ9CaO5/Lv0PDj5wCfZ4CGx2XZbq+qsFx9/GVK6eCy 6HQAoJvD81ghtJl7L9KGCvKyTXN9LF0j =2nq7 -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
how do I enable CGI scripts in Tomcat 6?
We have a web application running in Tomcat 6 on Ubuntu, and we want to run CGI scripts in Perl via the browser. The descriptions of the CGI enabling process that we have found on the Web, e.g. http://tomcat.apache.org/tomcat-6.0-doc/cgi-howto.html and http://www.wellho.net/solutions/java-running-cgi-scripts-in-apache-tomcat.html , seem simple enough, but they have not worked for us. We already had set context privileged=true in Tomcat's context.xml. We created a WEB-INF/cgi directory in our web app's hierarchy. In $CATALINA_BASE/conf/web.xml, we uncommented the CGI servlet description and servlet matching, and we set the cgiPathPrefix to WEB-INF/cgi/ and the servlet matching pattern to /cgi/*. (We also tried cgi/* and cgi-bin/* , with no better results.) We downloaded servlets-cgi.renametojar from a Tomcat 5 distribution, copied it into $CATALINA_BASE/lib/, renamed it to servlets-cgi.jar, and put a symlink to it in usr/share/tomcat6/lib/. (Tomcat 6 did not come with this file. Nor, for that matter, can we find a preexisting cgi-bin directory anywhere.) After each step we restarted Tomcat, but when we browse to a CGI script in WEB-INF/cgi/ (we actually access it through a symlink in a different, publicly accessible directory), the browser displays it simply as text instead of running it as a Perl script. The first line of the file says #!/usr/bin/perl, and we have confirmed that we have a working Perl installation at that location. Shortly thereafter, the file tells us we haven't configured our Web server to run CGI scripts. We also tried modifying our web app's WEB-INF/web.xml instead of the $CATALINA_BASE/conf/web.xml, but no joy. I'm sure we're missing something obvious to those in the know, but it's not obvious to us. Any suggestions would be welcome. - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
RE: how do I enable CGI scripts in Tomcat 6?
From: Grossman, Robert B [mailto:robert.gross...@uky.edu] Subject: how do I enable CGI scripts in Tomcat 6? The descriptions of the CGI enabling process that we have found on the Web, e.g. http://tomcat.apache.org/tomcat-6.0-doc/cgi-howto.html That's the right one. and http://www.wellho.net/solutions/java-running-cgi-scripts-in-apache-tomcat.html Sadly out of date and seriously broken. Use the real doc. We already had set context privileged=true in Tomcat's context.xml. That's wrong. First, it's Context, not context - case matters. Second, you shouldn't be setting this attribute globally, but rather in just the webapps that need it. We created a WEB-INF/cgi directory in our web app's hierarchy. In $CATALINA_BASE/conf/web.xml, we uncommented the CGI servlet description and servlet matching, and we set the cgiPathPrefix to WEB-INF/cgi/ and the servlet matching pattern to /cgi/*. Please post (via copy and paste) those sections of conf/web.xml so we can see what you actually did. Too often people see what they expect, not what's there. We downloaded servlets-cgi.renametojar from a Tomcat 5 distribution, Bad move. Where in the Tomcat 6 doc does it say to do that? You just broke your Tomcat 6 installation. Tomcat 6 did not come with this file. Because it doesn't need it. Nor, for that matter, can we find a preexisting cgi-bin directory anywhere. Nor should you. That's simply a part of the URL that triggers the CGI servlet, not an actual directory. The script path is specified by the cgiPathPrefix parameter. when we browse to a CGI script in WEB-INF/cgi/ (we actually access it through a symlink in a different, publicly accessible directory) Don't muck with symlinks until you've got it working. No point in introducing extra trouble spots until the basics are functional. - 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: More on Tomcat Sessions - limiting cluster session replication to sessions that will last longer than 'n' duration
Did you think about a possibility instead of get rid of the session overwriting the manager - getting rid of the data stored in session? If I understand correctly Tapestry needs the session for the page creation time ,which means that you don't need all the data stored there after the page was created (i would call it request context),right? You could _maybe_ do even better - look into Tapestry maybe it's data is marked in some way (i would guess it would ,for example with some prefix in attribute's name). And clean ,this only data ,after each request . I guess you can overwrite the Tomcat's Session (maybe will break the replication) or just configure a filter for this job. This is really simple ,the question is, will Tapestry work if you just throw away it's data after each request. Since I am not a Tapestry Guru i can't say . Hope this helps. Evgeny On Wed, Jan 13, 2010 at 12:19 AM, Robin Wilson rwil...@kingsisle.comwrote: Thanks for your response, here are my answers to your questions... In our test environment, we have a 2 server cluster, but our front-end Apache server is only hitting one of them. Regardless of that fact, all sessions created on either server get replicated to the other. So as they are created on the single test path, they get replicated to the second tomcat server. With only 2 cluster members, this isn't really a big deal (except for the load generators being able to create sessions faster than Tomcat can get rid of them). However, in our production environment we have 4 cluster members, so it only takes 1/4 of the load on each server to max out all 4 servers in terms of session creation speed. Keep in mind that during this situation, the _only_ problem we're seeing is that the sessions eventually fill up the heap. Performance remains good until the heap fills up and we start thrashing on Full GCs. (Clearly, more memory will help - by extending the duration we can sustain of peak loads, but a better solution will be to stop creating sessions for stuff that doesn't need it.) Your point is well taken about not creating the short-duration sessions, but alas, Tapestry is the chosen framework - and it uses the session as a mechanism to pass (more-or-less) global values between components of the page creation process. So ripping out that capability in Tapestry would require a massive change to our infrastructure. Your notes on the clustering (changes to DeltaManager) are right on target. So we adjusted when the DeltaManager creates the session until the end of processing, so that we know the timeout before we attempt to replicate it to other cluster members. That way, we already know the actual timeout duration before we decide whether to replicate. All of this would be unnecessary if there was some sort of session cleanup process that could dump expired sessions en masse every so often. Near as we can tell, each session has to be individually expired, which is why it lags so far behind the creation process. -- Robin D. Wilson Director of Web Development KingsIsle Entertainment, Inc. CELL: 512-426-3929 DESK: 512-623-5913 www.KingsIsle.com -Original Message- From: Christopher Schultz [mailto:ch...@christopherschultz.net] Sent: Tuesday, January 12, 2010 3:06 PM To: Tomcat Users List Subject: Re: More on Tomcat Sessions - limiting cluster session replication to sessions that will last longer than 'n' duration -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Robin, On 1/12/2010 1:42 PM, Robin Wilson wrote: Earlier this week I posted a question about how to prevent sessions from being created in our Tapestry pages, and/or how to get Tomcat to get rid of a bunch of '1-second' sessions we're creating during a load test because the sessions eventually fill up the heap. (They are being created faster than Tomcat can clean them out - even though they expire faster than we create them.) Well, they are eligible for expiration faster than they are being created. That session expiration thread can't be running /all/ the time :) So, my lead developer thinks he has found a way to alleviate our problems (at least for our production Tomcat 6.0.20 cluster of 4 servers). We will not replicate sessions to other cluster members unless they have a duration longer than a 'threshold' we set. Aah... I didn't realize that you were experiencing a session replication storm in your test setup. I thought you were only using a single app server for load testing. Did I misunderstand? We are altering the DeltaManager to make this change, so that simply creating a session doesn't automatically guarantee that it is replicated to other nodes in the cluster. The session duration will also have to be greater than a sessionDurationMinThreshold value we will set in the 'server.xml' file for the new DeltaManager. The idea is that sessions created that have very short durations are really 'transient' anyway, so there is no
rewrite not working in isapi_redirect
Hi, I am using ISAPI_REDIRECT in IIS, where I am redirecting all *.do pages to a worker. But now I want to redirect few urls to the new URLs like: /site/xyz.do = http://mysite.com/xyz.aspx I wrote the rule in rewrite file. /site/xyz.do=http://mysite.com/xyz.aspx But It didn't work. I gave an exclusion in the urimap file !/site/xyz.do=worker Even then it's not working. The other Issue is I am not getting any log file. SHould I make an empty log file myself at the destination log file address given to the redirector? Any help in the context wll be appreciated. Thanks... -- 'Make Your Own Way' Monu Agrawal
Re: rewrite not working in isapi_redirect
On 01/13/2010 07:45 AM, Monu Agrawal wrote: Hi, I am using ISAPI_REDIRECT in IIS, where I am redirecting all *.do pages to a worker. But now I want to redirect few urls to the new URLs like: /site/xyz.do = http://mysite.com/xyz.aspx I wrote the rule in rewrite file. /site/xyz.do=http://mysite.com/xyz.aspx But It didn't work. This is invalid target url. You should use /site/xyz.do=/xyz.aspx I gave an exclusion in the urimap file !/site/xyz.do=worker Even then it's not working. And it newer will. This means 'Let IIS handle the /site/xyz.do uri' probably ending in 404 You can setup IIS Http Redirect for that url which will cause 302 redirect to http://mysite.com/whatever The other Issue is I am not getting any log file. SHould I make an empty log file myself at the destination log file address given to the redirector? Your folder for log files probably doesn't have full access for the account IIS is running on. Regards -- ^TM - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
