Thanks for your reply Bruno! Your info has absolutely value for us. We do not have the resources to set up an environment similar to our customer's production server for testing and debugging, so your and others experiences is of great value. (Actually we recommended our customer not to use a web hotel, but a standalone server similar to what we had tested our application on.)
If others also has experienced something similar, we would very mutch like to know. -tommy -----Opprinnelig melding----- Fra: Bruno Georges [mailto:[EMAIL PROTECTED] Sendt: 12. mai 2006 10:32 Til: Tomcat Users List; users@tomcat.apache.org Emne: Re: Problems with Tomcat and sessions Tommy I don't know if this will be of any value to you but I had a similar case including session swapping. Users will see other users screens and data. Fairly nasty situation. We solved this problem by: Using prefork in apache 2 upgrading to a newer module. The problem was also occuring during pick activity. Our code wasn't changed. We assumed that the issue was the combination of apache mpm config and the old module. We also had DOS attacks from different time zones which contributed to some weird behaviour and made it harder to establish the root of the problem. To help we recreated the same environment as we had in production. This also helped us solved issues introduced with firewalls and load balancing. We then used webload, jmeter and proxysniffer to record activity and stress/load test our apps. Hopes this helps. Bruno Georges Glencore International AG Tel. +41 41 709 3204 Fax +41 41 709 3000 ----- Original Message ----- From: "Tommy Skarateppen" [EMAIL PROTECTED] Sent: 12.05.2006 10:05 To: <users@tomcat.apache.org> Subject: Problems with Tomcat and sessions Hi! We have a problem with a webapplication we have developed for one of our coustomers. The problem is that Tomcat is creating new sessions when it shouldn't. The sessions does not die, but a new is created and thus loosing access to the data in the original session. The result of the session "switching" is that the user is kicked out of the webapp, and can't log in until the "lost" session dies after 30 minutes (timeout). This does happen 10 - 20 times during the day, and it happens about the same time every day. At 10 - 11 in the morning and around 14 in the afternoon. This is when the traffic on the server is at its most. Our customer has the webapp in a Tomcat webhotel at an ISP, witch uses some Apache front end servers to proxy requests to the Tomcat server. We have checked our code thoroughly, and can't find anything there. Since this problem occure irregularly, and have never occured on our local test server, we suspect this is a server related problem. But we are not 100% sure, therefore this post to this list. I've searched the web to see if anyone else have had a similar problem, but haven't found anything we can relate to our problem. We know that there are 3 or 4 other webapps on the Tomcat hotel. The server has 1GB of physical RAM. Other tecnical info: Red Hat Linux release 7.3 (Valhalla) Tomcat 5.0.28 Java 1.4.2_10 maximum Java heap size: 512m We suspect the problem is either related to the use of front end servers or lack of memory. Does anyone of you have any suggestions on what can cause this trouble or point us in the right direction? -tommy --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] LEGAL DISCLAIMER. The contents of this e-mail and any attachments are strictly confidential and they may not be used or disclosed by someone who is not a named recipient. If you have received this email in error please notify the sender by replying to this email inserting the word "misdirected" as the message and delete this e-mail from your system. --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
