What a wonderfull world ..
WHAT A WONDERFUL WORLD I see trees of green, red roses too I see them bloom for me and you And I think to myself, what a wonderful world I see skies of blue and clouds of white The bright blessed day, the dark sacred night And I think to myself, what a wonderful world The colours of the rainbow, so pretty in the sky Are also on the faces of people going by I see friends shakin' hands, sayin' How do you do? They're really saying I love you I hear babies cryin', I watch them grow They'll learn much more than I'll ever know And I think to myself, what a wonderful world Yes, I think to myself, what a wonderful world Oh yeah Happy new Year .. Enjoy life ..Love thyself and others Thanks Regards, Vijay G Hatewar |Member of Technical Staff - TQE|Persistent Systems Pvt, Ltd., Pune.| |Ph: +91 .20 .3023.5331| Mobile: +91.9890678168| @: [EMAIL PROTECTED]| mailto:[EMAIL PROTECTED] DISCLAIMER == This e-mail may contain privileged and confidential information which is the property of Persistent Systems Pvt. Ltd. It is intended only for the use of the individual or entity to which it is addressed. If you are not the intended recipient, you are not authorized to read, retain, copy, print, distribute or use this message. If you have received this communication in error, please notify the sender and delete all copies of this message. Persistent Systems Pvt. Ltd. does not accept any liability for virus infected mails.
Re: session#getId changes during doGet invocation under heavy load
I am gathering more evidence that this is related to a session expiring on one hand and a request being processed for that same session. I have been debugging the tomcat code a bit, and I have the *impression* that the expiration handling is not thread safe. It seems possible at first sight that the background processor decides a session is expired while at the same time another thread starts a request for that same session. I will try to debug a bit more and if I find more I will let you know. Thanks, Peter PS What does O/T mean ? Martin Gainty wrote: Agreed Once you have your use cases and test cases identified If you want the server to maintain its own side of the relationship independent of client activity then you should consider container managed persistence More info avaialable at http://www.javaworld.com/javaworld/jw-08-2006/jw-0828-persistence.html?page=6 Feel free to contact me offline as this is definitely O/T Martin-- --- This e-mail message (including attachments, if any) is intended for the use of the individual or entity to which it is addressed and may contain information that is privileged, proprietary , confidential and exempt from disclosure. If you are not the intended recipient, you are notified that any dissemination, distribution or copying of this communication is strictly prohibited. --- Le présent message électronique (y compris les pièces qui y sont annexées, le cas échéant) s'adresse au destinataire indiqué et peut contenir des renseignements de caractère privé ou confidentiel. Si vous n'êtes pas le destinataire de ce document, nous vous signalons qu'il est strictement interdit de le diffuser, de le distribuer ou de le reproduire. - Original Message - From: Leon Rosenberg [EMAIL PROTECTED] To: Tomcat Users List users@tomcat.apache.org Sent: Friday, December 29, 2006 6:31 AM Subject: Re: session#getId changes during doGet invocation under heavy load Do I understand it right, that you made it a reproduceable testcase? If so, can we have a look on it? thank you Leon On 12/29/06, Peter Coppens [EMAIL PROTECTED] wrote: Thanks Chuck. I have done some further research and I have the impression that there is some kind of race condition where a session that is being removed because of a timeout is also handling requests. The loggings indicate that a session is destroyed but then nevertheless a doGet is invoked with a request parameter that refers to that timed out session. If I crank up the timeout, seriously reducing the chances a session times out before it has completed all the client requests it is supposed to handle during the test, the problem does no longer occur. I am not sure where that leaves me. I am still uncertain as to what the servlet is doing wrong. Would you (or anyone else) have any other comments on this? Thanks, Peter Caldarale, Charles R wrote: From: Peter Coppens [mailto:[EMAIL PROTECTED] Subject: session#getId changes during doGet invocation under heavy load THe problem I run into is that, under heavy load, during the doGet invocation for the login request the session attached to the request is changed by some other thread (the value returned from getId changes and attributes that are originally set are removed). This is most likely an application problem - storing session- or request-specific data in an inappropriately scoped structure (e.g., a servlet field). Under light load, this won't hurt, since the insertion and retrieval for a given request don't overlap any other requests. As the load increases, so does the probability of an overlap and erroneous retrieval of data for another request. - 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 start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- View this message in context: http://www.nabble.com/session-getId-changes-during-doGet-invocation-under-heavy-load-tf2892448.html#a8085181 Sent from the Tomcat - User mailing list archive at Nabble.com. - To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL
Re: session#getId changes during doGet invocation under heavy load
On 12/30/06, Peter Coppens [EMAIL PROTECTED] wrote: I am gathering more evidence that this is related to a session expiring on one hand and a request being processed for that same session. I have been debugging the tomcat code a bit, and I have the *impression* that the expiration handling is not thread safe. It seems possible at first sight that the background processor decides a session is expired while at the same time another thread starts a request for that same session. I will try to debug a bit more and if I find more I will let you know. The question is whether the next request get the right session again or not. I had the impression from your first post, that this is the case: Request A - Session 1 Request B - Session 2 -- which is wrong Request C - Session 1 again. I observed this behaviour 3 years ago on a resin 2.1.x, but had not enough time to debug it. regards Leon Thanks, Peter PS What does O/T mean ? Off Topic Martin Gainty wrote: Agreed Once you have your use cases and test cases identified If you want the server to maintain its own side of the relationship independent of client activity then you should consider container managed persistence More info avaialable at http://www.javaworld.com/javaworld/jw-08-2006/jw-0828-persistence.html?page=6 Feel free to contact me offline as this is definitely O/T Martin-- --- This e-mail message (including attachments, if any) is intended for the use of the individual or entity to which it is addressed and may contain information that is privileged, proprietary , confidential and exempt from disclosure. If you are not the intended recipient, you are notified that any dissemination, distribution or copying of this communication is strictly prohibited. --- Le présent message électronique (y compris les pièces qui y sont annexées, le cas échéant) s'adresse au destinataire indiqué et peut contenir des renseignements de caractère privé ou confidentiel. Si vous n'êtes pas le destinataire de ce document, nous vous signalons qu'il est strictement interdit de le diffuser, de le distribuer ou de le reproduire. - Original Message - From: Leon Rosenberg [EMAIL PROTECTED] To: Tomcat Users List users@tomcat.apache.org Sent: Friday, December 29, 2006 6:31 AM Subject: Re: session#getId changes during doGet invocation under heavy load Do I understand it right, that you made it a reproduceable testcase? If so, can we have a look on it? thank you Leon On 12/29/06, Peter Coppens [EMAIL PROTECTED] wrote: Thanks Chuck. I have done some further research and I have the impression that there is some kind of race condition where a session that is being removed because of a timeout is also handling requests. The loggings indicate that a session is destroyed but then nevertheless a doGet is invoked with a request parameter that refers to that timed out session. If I crank up the timeout, seriously reducing the chances a session times out before it has completed all the client requests it is supposed to handle during the test, the problem does no longer occur. I am not sure where that leaves me. I am still uncertain as to what the servlet is doing wrong. Would you (or anyone else) have any other comments on this? Thanks, Peter Caldarale, Charles R wrote: From: Peter Coppens [mailto:[EMAIL PROTECTED] Subject: session#getId changes during doGet invocation under heavy load THe problem I run into is that, under heavy load, during the doGet invocation for the login request the session attached to the request is changed by some other thread (the value returned from getId changes and attributes that are originally set are removed). This is most likely an application problem - storing session- or request-specific data in an inappropriately scoped structure (e.g., a servlet field). Under light load, this won't hurt, since the insertion and retrieval for a given request don't overlap any other requests. As the load increases, so does the probability of an overlap and erroneous retrieval of data for another request. - 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 start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- View this message in context: http://www.nabble.com/session-getId-changes-during-doGet-invocation-under-heavy-load-tf2892448.html#a8085181 Sent from the Tomcat - User mailing list archive at
[OT] Will you install VISTA?
Hi, I don't want to start a flame war on microsoft or something, but I stubbled on this article and was quite shocked what vista really is... Maybe you will be shocked as well, maybe you don't care, but it's worth reading anyway :-) http://www.cs.auckland.ac.nz/~pgut001/pubs/vista_cost.txt regards and happy new year! Leon - To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [OT] Will you install VISTA?
Is'nt this the OS that walks on water? Thanks Leon, M- --- This e-mail message (including attachments, if any) is intended for the use of the individual or entity to which it is addressed and may contain information that is privileged, proprietary , confidential and exempt from disclosure. If you are not the intended recipient, you are notified that any dissemination, distribution or copying of this communication is strictly prohibited. --- Le présent message électronique (y compris les pièces qui y sont annexées, le cas échéant) s'adresse au destinataire indiqué et peut contenir des renseignements de caractère privé ou confidentiel. Si vous n'êtes pas le destinataire de ce document, nous vous signalons qu'il est strictement interdit de le diffuser, de le distribuer ou de le reproduire. - Original Message - From: Leon Rosenberg [EMAIL PROTECTED] To: Tomcat Users List users@tomcat.apache.org; Struts Users Mailing List user@struts.apache.org Sent: Saturday, December 30, 2006 9:02 AM Subject: [OT] Will you install VISTA? Hi, I don't want to start a flame war on microsoft or something, but I stubbled on this article and was quite shocked what vista really is... Maybe you will be shocked as well, maybe you don't care, but it's worth reading anyway :-) http://www.cs.auckland.ac.nz/~pgut001/pubs/vista_cost.txt regards and happy new year! Leon - To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [OT] Will you install VISTA?
Linux has chance to become top platform for watching and coping pirate HD-DVD :) I guess there would be Ubuntu Media Edition soon or Mubuntu. Happy New Year! Saturday, December 30, 2006, 4:02:48 PM, you wrote: LR Hi, LR I don't want to start a flame war on microsoft or something, but I LR stubbled on this article and was quite shocked what vista really is... LR Maybe you will be shocked as well, maybe you don't care, but it's LR worth reading anyway :-) LR http://www.cs.auckland.ac.nz/~pgut001/pubs/vista_cost.txt LR regards and happy new year! LR Leon LR - LR To start a new topic, e-mail: users@tomcat.apache.org LR To unsubscribe, e-mail: [EMAIL PROTECTED] LR For additional commands, e-mail: [EMAIL PROTECTED] -- Best regards, Dimamailto:[EMAIL PROTECTED] - To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [OT] Will you install VISTA? (NO, I keep my W2K)
Hi, I don't want to start a flame war on microsoft or something, but I stubbled on this article and was quite shocked what vista really is... Maybe you will be shocked as well, maybe you don't care, but it's worth reading anyway :-) http://www.cs.auckland.ac.nz/~pgut001/pubs/vista_cost.txt regards and happy new year! Leon I see the article on Vista's DRM madness is making its round. It's a weird world when a company mainly renowned for issuing some consumer-level operating system code at monopoly prices starts to mandate hardware systems that are able to resist a Cylon hack attack or that will self-destruct if all else fails ... but still no-one bothers to keep your credit card numbers secure. This is going to get interesting. Happy new year and keep those Tomcats coming! -- David - To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: error-page http status 408
Nope, my server is only running Tomcat. There is nothing else involved. -rg On 12/30/06, Mark Thomas [EMAIL PROTECTED] wrote: rg wrote: I am using Tomcat 5.5.17 on Windows. I have a problem setting a 408 error-page in my web.xml on form based authentication. Random thought. Are you using httpd at all? If so, try going direct to Tomcat and getting that to work first. Mark - To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: session#getId changes during doGet invocation under heavy load
Actually it just seems to be related to the fact that under heavy load the db connection starts to take longer than the timeout. Apparently, a call to request.getSession() somewhere in the middel of the doGet processing will also trigger invalidating the session, which is kind of a nuisance as one should then apparently constantly check whether the session has not expired during request processing. I assume this is Servlet spec compliant, but it does seem to make my life rather complex. Would there be anyone having any suggestions to deal with this. Thanks, Peter Leon Rosenberg-3 wrote: On 12/30/06, Peter Coppens [EMAIL PROTECTED] wrote: I am gathering more evidence that this is related to a session expiring on one hand and a request being processed for that same session. I have been debugging the tomcat code a bit, and I have the *impression* that the expiration handling is not thread safe. It seems possible at first sight that the background processor decides a session is expired while at the same time another thread starts a request for that same session. I will try to debug a bit more and if I find more I will let you know. The question is whether the next request get the right session again or not. I had the impression from your first post, that this is the case: Request A - Session 1 Request B - Session 2 -- which is wrong Request C - Session 1 again. I observed this behaviour 3 years ago on a resin 2.1.x, but had not enough time to debug it. regards Leon Thanks, Peter PS What does O/T mean ? Off Topic Martin Gainty wrote: Agreed Once you have your use cases and test cases identified If you want the server to maintain its own side of the relationship independent of client activity then you should consider container managed persistence More info avaialable at http://www.javaworld.com/javaworld/jw-08-2006/jw-0828-persistence.html?page=6 Feel free to contact me offline as this is definitely O/T Martin-- --- This e-mail message (including attachments, if any) is intended for the use of the individual or entity to which it is addressed and may contain information that is privileged, proprietary , confidential and exempt from disclosure. If you are not the intended recipient, you are notified that any dissemination, distribution or copying of this communication is strictly prohibited. --- Le présent message électronique (y compris les pièces qui y sont annexées, le cas échéant) s'adresse au destinataire indiqué et peut contenir des renseignements de caractère privé ou confidentiel. Si vous n'êtes pas le destinataire de ce document, nous vous signalons qu'il est strictement interdit de le diffuser, de le distribuer ou de le reproduire. - Original Message - From: Leon Rosenberg [EMAIL PROTECTED] To: Tomcat Users List users@tomcat.apache.org Sent: Friday, December 29, 2006 6:31 AM Subject: Re: session#getId changes during doGet invocation under heavy load Do I understand it right, that you made it a reproduceable testcase? If so, can we have a look on it? thank you Leon On 12/29/06, Peter Coppens [EMAIL PROTECTED] wrote: Thanks Chuck. I have done some further research and I have the impression that there is some kind of race condition where a session that is being removed because of a timeout is also handling requests. The loggings indicate that a session is destroyed but then nevertheless a doGet is invoked with a request parameter that refers to that timed out session. If I crank up the timeout, seriously reducing the chances a session times out before it has completed all the client requests it is supposed to handle during the test, the problem does no longer occur. I am not sure where that leaves me. I am still uncertain as to what the servlet is doing wrong. Would you (or anyone else) have any other comments on this? Thanks, Peter Caldarale, Charles R wrote: From: Peter Coppens [mailto:[EMAIL PROTECTED] Subject: session#getId changes during doGet invocation under heavy load THe problem I run into is that, under heavy load, during the doGet invocation for the login request the session attached to the request is changed by some other thread (the value returned from getId changes and attributes that are originally set are removed). This is most likely an application problem - storing session- or request-specific data in an inappropriately scoped structure (e.g., a servlet field). Under light load, this won't hurt, since the insertion and retrieval for a given request don't overlap any other requests. As the load increases, so does the probability of an overlap and erroneous retrieval of
RE: How can JSPs be part of an integrated component?
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Subject: Re: How can JSPs be part of an integrated component? Sure, that works if you're banking on Tomcat as your deployment target, but the classes that you've compiled and hardwired (there many lines of hardwiring in the admin web.xml) to Tomcat. None of what's in web.xml is specific to Tomcat - it's all defined by the servlet spec, and is usable on any container. (What the admin app actually does is certainly specific to Tomcat, of course, but the pre-compilation mechanism is not.) Compiling the JSP files into classes and generating the multitude of servlet mappings is normally done by an ANT script, of which there are numerous examples floating around. - 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 start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: How can JSPs be part of an integrated component?
It's not the web.xml that's specific to Tomcat, it's the compiled JSP
classes (to be frank other JSP compilers might select totally different
filenames rendering the web.xml specific to Tomcat too).
Have a look at the .class files that are in the catalina-admin.jar. The
classes look like:
package admin;
public final class banner_jsp
extends org.apache.jasper.runtime.HttpJspBase
implements org.apache.jasper.runtime.JspSourceDependent
{
private static java.util.Vector _jspx_dependants;
private org.apache.jasper.runtime.TagHandlerPool
_jspx_tagPool_html_html_locale;
I'm going to have a look at what changes would be required to serve jsp's
directly from jars in the web-inf directory to solve my problem. Container
specific .war files doesn't seem the way to go.
Thanks.
--lee
On 12/30/06, Caldarale, Charles R [EMAIL PROTECTED] wrote:
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
Subject: Re: How can JSPs be part of an integrated component?
Sure, that works if you're banking on Tomcat as your
deployment target, but the classes that you've compiled
and hardwired (there many lines of hardwiring in the
admin web.xml) to Tomcat.
None of what's in web.xml is specific to Tomcat - it's all defined by
the servlet spec, and is usable on any container. (What the admin app
actually does is certainly specific to Tomcat, of course, but the
pre-compilation mechanism is not.) Compiling the JSP files into classes
and generating the multitude of servlet mappings is normally done by an
ANT script, of which there are numerous examples floating around.
- 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 start a new topic, e-mail: users@tomcat.apache.org
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
How to run tomcat service in JDK6?
I first downloaded windows service installer of 5.5.20 and can't get it work, then I switched to zip file version. Reason is I checked doc for how-to and it indicated service.bat which can only be found in zip version. I followed how-to and ran service.bat install, which was successful based on console as below, Installing the service 'Tomcat5' ... Using CATALINA_HOME:C:\tomcat-5.5.20 Using CATALINA_BASE:C:\tomcat-5.5.20 Using JAVA_HOME:C:\Program Files\Java\jdk1.6.0 Using JVM: C:\Program Files\Java\jdk1.6.0\jre\bin\server\jvm.dll The service 'Tomcat5' has been installed. Then I clicked tomcat5w.exe and chose start button, but status still showed stopped. I checked log file which showed me following info, [2006-12-29 23:27:47] [info] Starting service... [2006-12-29 23:27:47] [173 javajni.c] [error] The specified module could not be found. [2006-12-29 23:27:47] [924 prunsrv.c] [error] Failed creating java C:\Program Files\Java\jdk1.6.0\jre\bin\server\jvm.dll [2006-12-29 23:27:47] [1179 prunsrv.c] [error] ServiceStart returned 1 [2006-12-29 23:27:47] [info] Run service finished. [2006-12-29 23:27:47] [info] Procrun finished. Some configuration in tomcat5w.exe are, (General tab)Path to execute: C:\tomcat-5.5.20\bin\tomcat5.exe //RS//Tomcat5 (Java tab)Use default: not checked; Java Virtual Machine: C:\Program Files\Java\jdk1.6.0\jre\bin\server\jvm.dll Java Classpath: C:\tomcat-5.5.20\bin\bootstrap.jar Java Options: -Dcatalina.base=C:\tomcat-5.5.20 -Dcatalina.home=C:\tomcat-5.5.20 -Djava.endorsed.dirs=C:\tomcat-5.5.20\common\endorsed -Djava.io.tmpdir=C:\tomcat-5.5.20\temp (Startup tab) Class: org.apache.catalina.startup.Bootstrap Working Path: empty (I even tried putting C:\tomcat-5.5.20 here, but still doesn't work) Methods: empty Argument: start Mode: jvm Has anyone used JDK 6 for 5.5.20? Any idea? Thanks and Happy New Year! -- View this message in context: http://www.nabble.com/How-to-run-tomcat-service-in-JDK6--tf2899055.html#a8099595 Sent from the Tomcat - User mailing list archive at Nabble.com. - To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: How can JSPs be part of an integrated component?
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Subject: Re: How can JSPs be part of an integrated component? public final class banner_jsp extends org.apache.jasper.runtime.HttpJspBase implements org.apache.jasper.runtime.JspSourceDependent Jasper is not Tomcat-specific - it's used by a variety of containers to translate JSPs into Java code, so as long as you package the Jasper run-time with your webapp, I don't think you'll have a problem. - 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 start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: run service in jdk 6
From: kkus [mailto:[EMAIL PROTECTED] Subject: How to run tomcat service in JDK6? Double-posting won't improve your chances of getting an answer, but it will annoy people. Has anyone used JDK 6 for 5.5.20? Any idea? I'm using it right now, with no problems. However, the JDK is installed in C:\jdk1.6.0, rather than a directory with spaces embedded in the name (another brilliant Microsoft innovation). - 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 start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: run service in jdk 6
I just installed 5.5.20 with JDK 1.6.0 on Windows XP. Run smooth as service. No problem at all. Following is my configuration: (1) Install java in c:\jdk1.6.0. Also set JAVA_HOME (2) While installing tomcat, it detected jre from c:\Program Files\Java\jre1.6.0 and installed Tomcat in c:\Tomcat5.5 (3) Start menu tomcat entries created as they were. Everything works out of box. Though my service is manual. But I don't think that makes big difference. Hope it helps. Try reinstalling java. Also please check your java installation is correct. One good way to test is see if you can able to run Netbeans correctly. Regards, D --- Caldarale, Charles R [EMAIL PROTECTED] wrote: From: kkus [mailto:[EMAIL PROTECTED] Subject: How to run tomcat service in JDK6? Double-posting won't improve your chances of getting an answer, but it will annoy people. Has anyone used JDK 6 for 5.5.20? Any idea? I'm using it right now, with no problems. However, the JDK is installed in C:\jdk1.6.0, rather than a directory with spaces embedded in the name (another brilliant Microsoft innovation). - 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 start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com - To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: session#getId changes during doGet invocation under heavy load
On 12/30/06, Peter Coppens [EMAIL PROTECTED] wrote: Actually it just seems to be related to the fact that under heavy load the db connection starts to take longer than the timeout. Thats a lot. What is your timeout configured to? Apparently, a call to request.getSession() somewhere in the middel of the doGet processing will also trigger invalidating the session, which is kind of a nuisance as one should then apparently constantly check whether the session has not expired during request processing. I assume this is Servlet spec compliant, but it does seem to make my life rather complex. Would there be anyone having any suggestions to deal with this. We might need some more details on your application to give you meaningful suggestions, but just from the hip I'd say following: 1. You make DB requests not only from tomcat which is suboptimal anyway, but also directly from the servlet, which would mean that you utterly need to refactor your application anyway. 2. Apparently your timeouts are way to low. On the other hand, it can't be healthy if your requests last longer than hours (default timeout for the session are 2 hours) 3. In case you can't change anything other, you could consider starting a thread on the start of the request which just calls session.get/put with dummy attributes periodically to prevent the session from being timeouted. However this feature has to be implemented carefully, since it can cause much harm with regard to garbage collection if your thread instances sticks and keep references to the session or similar. By the way, what do you mean by heavy load? Regards Leon Thanks, Peter Leon Rosenberg-3 wrote: On 12/30/06, Peter Coppens [EMAIL PROTECTED] wrote: I am gathering more evidence that this is related to a session expiring on one hand and a request being processed for that same session. I have been debugging the tomcat code a bit, and I have the *impression* that the expiration handling is not thread safe. It seems possible at first sight that the background processor decides a session is expired while at the same time another thread starts a request for that same session. I will try to debug a bit more and if I find more I will let you know. The question is whether the next request get the right session again or not. I had the impression from your first post, that this is the case: Request A - Session 1 Request B - Session 2 -- which is wrong Request C - Session 1 again. I observed this behaviour 3 years ago on a resin 2.1.x, but had not enough time to debug it. regards Leon Thanks, Peter PS What does O/T mean ? Off Topic Martin Gainty wrote: Agreed Once you have your use cases and test cases identified If you want the server to maintain its own side of the relationship independent of client activity then you should consider container managed persistence More info avaialable at http://www.javaworld.com/javaworld/jw-08-2006/jw-0828-persistence.html?page=6 Feel free to contact me offline as this is definitely O/T Martin-- --- This e-mail message (including attachments, if any) is intended for the use of the individual or entity to which it is addressed and may contain information that is privileged, proprietary , confidential and exempt from disclosure. If you are not the intended recipient, you are notified that any dissemination, distribution or copying of this communication is strictly prohibited. --- Le présent message électronique (y compris les pièces qui y sont annexées, le cas échéant) s'adresse au destinataire indiqué et peut contenir des renseignements de caractère privé ou confidentiel. Si vous n'êtes pas le destinataire de ce document, nous vous signalons qu'il est strictement interdit de le diffuser, de le distribuer ou de le reproduire. - Original Message - From: Leon Rosenberg [EMAIL PROTECTED] To: Tomcat Users List users@tomcat.apache.org Sent: Friday, December 29, 2006 6:31 AM Subject: Re: session#getId changes during doGet invocation under heavy load Do I understand it right, that you made it a reproduceable testcase? If so, can we have a look on it? thank you Leon On 12/29/06, Peter Coppens [EMAIL PROTECTED] wrote: Thanks Chuck. I have done some further research and I have the impression that there is some kind of race condition where a session that is being removed because of a timeout is also handling requests. The loggings indicate that a session is destroyed but then nevertheless a doGet is invoked with a request parameter that refers to that timed out session. If I crank up the timeout, seriously reducing the chances a session times out before it has completed all the client requests it is supposed to handle during the
Re: session#getId changes during doGet invocation under heavy load
Hmm... I can see two senarios that can cause this situation: 1. Your sessions are configured to be way too short. I'd recommend at sessions live at least until the request times out. 2. You have a reference to the session in a servlet instance -- either directly or indirectly. Keep in mind that servlets are recycled between requests and should be entirely stateless. Class instance properties should be avoided. In this case an old session is continuously reused for several requests even after it's been invalidated. Even if these two suggestions aren't an exact fit to your issue, maybe they can seed some ideas on what's going on. --David Peter Coppens wrote: Actually it just seems to be related to the fact that under heavy load the db connection starts to take longer than the timeout. Apparently, a call to request.getSession() somewhere in the middel of the doGet processing will also trigger invalidating the session, which is kind of a nuisance as one should then apparently constantly check whether the session has not expired during request processing. I assume this is Servlet spec compliant, but it does seem to make my life rather complex. Would there be anyone having any suggestions to deal with this. Thanks, Peter Leon Rosenberg-3 wrote: On 12/30/06, Peter Coppens [EMAIL PROTECTED] wrote: I am gathering more evidence that this is related to a session expiring on one hand and a request being processed for that same session. I have been debugging the tomcat code a bit, and I have the *impression* that the expiration handling is not thread safe. It seems possible at first sight that the background processor decides a session is expired while at the same time another thread starts a request for that same session. I will try to debug a bit more and if I find more I will let you know. The question is whether the next request get the right session again or not. I had the impression from your first post, that this is the case: Request A - Session 1 Request B - Session 2 -- which is wrong Request C - Session 1 again. I observed this behaviour 3 years ago on a resin 2.1.x, but had not enough time to debug it. regards Leon Thanks, Peter PS What does O/T mean ? Off Topic Martin Gainty wrote: Agreed Once you have your use cases and test cases identified If you want the server to maintain its own side of the relationship independent of client activity then you should consider container managed persistence More info avaialable at http://www.javaworld.com/javaworld/jw-08-2006/jw-0828-persistence.html?page=6 Feel free to contact me offline as this is definitely O/T Martin-- --- This e-mail message (including attachments, if any) is intended for the use of the individual or entity to which it is addressed and may contain information that is privileged, proprietary , confidential and exempt from disclosure. If you are not the intended recipient, you are notified that any dissemination, distribution or copying of this communication is strictly prohibited. --- Le présent message électronique (y compris les pièces qui y sont annexées, le cas échéant) s'adresse au destinataire indiqué et peut contenir des renseignements de caractère privé ou confidentiel. Si vous n'êtes pas le destinataire de ce document, nous vous signalons qu'il est strictement interdit de le diffuser, de le distribuer ou de le reproduire. - Original Message - From: Leon Rosenberg [EMAIL PROTECTED] To: Tomcat Users List users@tomcat.apache.org Sent: Friday, December 29, 2006 6:31 AM Subject: Re: session#getId changes during doGet invocation under heavy load Do I understand it right, that you made it a reproduceable testcase? If so, can we have a look on it? thank you Leon On 12/29/06, Peter Coppens [EMAIL PROTECTED] wrote: Thanks Chuck. I have done some further research and I have the impression that there is some kind of race condition where a session that is being removed because of a timeout is also handling requests. The loggings indicate that a session is destroyed but then nevertheless a doGet is invoked with a request parameter that refers to that timed out session. If I crank up the timeout, seriously reducing the chances a session times out before it has completed all the client requests it is supposed to handle during the test, the problem does no longer occur. I am not sure where that leaves me. I am still uncertain as to what the servlet is doing wrong. Would you (or anyone else) have any other comments on this? Thanks,
Re: session#getId changes during doGet invocation under heavy load
Thanks for the suggestions. I have been playing with the timeouts to trigger the problem. Typically I would like to have them around 15minutesand yes that is apparently not sufficient for the load test I am doing. The setup is three machines. One with tomcat running that connects to a 2nd one running MySQL. THe third is running jMeter (300 'users'). That said, I am baffled by the fact that some connections take 15minutes. From the start, I included a dbcp pool to try and optimize the db resource usage, but I am starting to wonder whether that is not causing more problems than it is solving. I'll try to isolate the dbcp pool code and see how that behaves. In the end I guess it can also be the db server. For now I am going to try to not have timeouts during doGet processing, rather than try to deal with them. Something I did not understand from the suggestions is 1. You make DB requests not only from tomcat which is suboptimal anyway, but also directly from the servlet, which would mean that you utterly need to refactor your application anyway. I am not sure I understand the difference from tomcat versus from the servlet Again, all suggestions warmly welcomed! Peter Leon Rosenberg-3 wrote: On 12/30/06, Peter Coppens [EMAIL PROTECTED] wrote: Actually it just seems to be related to the fact that under heavy load the db connection starts to take longer than the timeout. Thats a lot. What is your timeout configured to? Apparently, a call to request.getSession() somewhere in the middel of the doGet processing will also trigger invalidating the session, which is kind of a nuisance as one should then apparently constantly check whether the session has not expired during request processing. I assume this is Servlet spec compliant, but it does seem to make my life rather complex. Would there be anyone having any suggestions to deal with this. We might need some more details on your application to give you meaningful suggestions, but just from the hip I'd say following: 1. You make DB requests not only from tomcat which is suboptimal anyway, but also directly from the servlet, which would mean that you utterly need to refactor your application anyway. 2. Apparently your timeouts are way to low. On the other hand, it can't be healthy if your requests last longer than hours (default timeout for the session are 2 hours) 3. In case you can't change anything other, you could consider starting a thread on the start of the request which just calls session.get/put with dummy attributes periodically to prevent the session from being timeouted. However this feature has to be implemented carefully, since it can cause much harm with regard to garbage collection if your thread instances sticks and keep references to the session or similar. By the way, what do you mean by heavy load? Regards Leon Thanks, Peter Leon Rosenberg-3 wrote: On 12/30/06, Peter Coppens [EMAIL PROTECTED] wrote: I am gathering more evidence that this is related to a session expiring on one hand and a request being processed for that same session. I have been debugging the tomcat code a bit, and I have the *impression* that the expiration handling is not thread safe. It seems possible at first sight that the background processor decides a session is expired while at the same time another thread starts a request for that same session. I will try to debug a bit more and if I find more I will let you know. The question is whether the next request get the right session again or not. I had the impression from your first post, that this is the case: Request A - Session 1 Request B - Session 2 -- which is wrong Request C - Session 1 again. I observed this behaviour 3 years ago on a resin 2.1.x, but had not enough time to debug it. regards Leon Thanks, Peter PS What does O/T mean ? Off Topic Martin Gainty wrote: Agreed Once you have your use cases and test cases identified If you want the server to maintain its own side of the relationship independent of client activity then you should consider container managed persistence More info avaialable at http://www.javaworld.com/javaworld/jw-08-2006/jw-0828-persistence.html?page=6 Feel free to contact me offline as this is definitely O/T Martin-- --- This e-mail message (including attachments, if any) is intended for the use of the individual or entity to which it is addressed and may contain information that is privileged, proprietary , confidential and exempt from disclosure. If you are not the intended recipient, you are notified that any dissemination, distribution or copying of this communication is strictly prohibited. --- Le
Re: What a wonderfull world ..
thanks On 12/30/06, Vijay Hatewar [EMAIL PROTECTED] wrote: WHAT A WONDERFUL WORLD I see trees of green, red roses too I see them bloom for me and you And I think to myself, what a wonderful world I see skies of blue and clouds of white The bright blessed day, the dark sacred night And I think to myself, what a wonderful world The colours of the rainbow, so pretty in the sky Are also on the faces of people going by I see friends shakin' hands, sayin' How do you do? They're really saying I love you I hear babies cryin', I watch them grow They'll learn much more than I'll ever know And I think to myself, what a wonderful world Yes, I think to myself, what a wonderful world Oh yeah Happy new Year .. Enjoy life ..Love thyself and others Thanks Regards, Vijay G Hatewar |Member of Technical Staff - TQE|Persistent Systems Pvt, Ltd., Pune.| |Ph: +91 .20 .3023.5331| Mobile: +91.9890678168| @: [EMAIL PROTECTED]| mailto:[EMAIL PROTECTED] DISCLAIMER == This e-mail may contain privileged and confidential information which is the property of Persistent Systems Pvt. Ltd. It is intended only for the use of the individual or entity to which it is addressed. If you are not the intended recipient, you are not authorized to read, retain, copy, print, distribute or use this message. If you have received this communication in error, please notify the sender and delete all copies of this message. Persistent Systems Pvt. Ltd. does not accept any liability for virus infected mails. - To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: session#getId changes during doGet invocation under heavy load
On 12/30/06, Peter Coppens [EMAIL PROTECTED] wrote: That said, I am baffled by the fact that some connections take 15minutes. Are you referring to MySQL connection setup time? Or query time? Either way, it certainly doesn't sound like a Tomcat problem... :-) -- Hassan Schroeder [EMAIL PROTECTED] - To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: session#getId changes during doGet invocation under heavy load
Are you referring to MySQL connection setup time? Or query time? Connection time (using a dbcp pool) Either way, it certainly doesn't sound like a Tomcat problem... :-) Absolutely agree. -- View this message in context: http://www.nabble.com/session-getId-changes-during-doGet-invocation-under-heavy-load-tf2892448.html#a8101076 Sent from the Tomcat - User mailing list archive at Nabble.com. - To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Multi processor issue
Mark Thomas wrote: I plan to look at modifying the current RD code over the holiday. In 5.5.21 onwards, the RD will be thread safe so the OP's code should work without modification. Mark - To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: What a wonderfull world ..
Im still waiting for the usual insults from chuck..then again maybe he took the day off.. --- This e-mail message (including attachments, if any) is intended for the use of the individual or entity to which it is addressed and may contain information that is privileged, proprietary , confidential and exempt from disclosure. If you are not the intended recipient, you are notified that any dissemination, distribution or copying of this communication is strictly prohibited. --- Le présent message électronique (y compris les pièces qui y sont annexées, le cas échéant) s'adresse au destinataire indiqué et peut contenir des renseignements de caractère privé ou confidentiel. Si vous n'êtes pas le destinataire de ce document, nous vous signalons qu'il est strictement interdit de le diffuser, de le distribuer ou de le reproduire. - Original Message - From: Almir Kazazic [EMAIL PROTECTED] To: Tomcat Users List users@tomcat.apache.org Sent: Saturday, December 30, 2006 2:16 PM Subject: Re: What a wonderfull world .. thanks On 12/30/06, Vijay Hatewar [EMAIL PROTECTED] wrote: WHAT A WONDERFUL WORLD I see trees of green, red roses too I see them bloom for me and you And I think to myself, what a wonderful world I see skies of blue and clouds of white The bright blessed day, the dark sacred night And I think to myself, what a wonderful world The colours of the rainbow, so pretty in the sky Are also on the faces of people going by I see friends shakin' hands, sayin' How do you do? They're really saying I love you I hear babies cryin', I watch them grow They'll learn much more than I'll ever know And I think to myself, what a wonderful world Yes, I think to myself, what a wonderful world Oh yeah Happy new Year .. Enjoy life ..Love thyself and others Thanks Regards, Vijay G Hatewar |Member of Technical Staff - TQE|Persistent Systems Pvt, Ltd., Pune.| |Ph: +91 .20 .3023.5331| Mobile: +91.9890678168| @: [EMAIL PROTECTED]| mailto:[EMAIL PROTECTED] DISCLAIMER == This e-mail may contain privileged and confidential information which is the property of Persistent Systems Pvt. Ltd. It is intended only for the use of the individual or entity to which it is addressed. If you are not the intended recipient, you are not authorized to read, retain, copy, print, distribute or use this message. If you have received this communication in error, please notify the sender and delete all copies of this message. Persistent Systems Pvt. Ltd. does not accept any liability for virus infected mails. - To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: What a wonderfull world ..
Martin Gainty wrote: Im still waiting for the usual insults from chuck..then again maybe he took the day off.. Martin, This sort of comment is completely out of line. There is no justification whatsoever for your behaviour on this thread. I expect to see a public apology on this thread from you to Chuck forthwith. This is the second time I have had to ask you to apologise to Chuck. You ignored my request the last time, I do not expect to be ignored a second time. Mark [EMAIL PROTECTED] - To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: session#getId changes during doGet invocation under heavy load
Also be aware of the distinction between Request.getSession(true) and Request.getSession(false) where Request.getSession(true) will attempt to create a new session (if none exists) Request.getSession(false) will NOT create a new session (perhaps you should use option 2) Also which mechanism are you are using to create,prepare,execute and commit your DB statement? It appears you *may* have some asynchronous operations executing which may not be synchronsing to the invoking call M- --- This e-mail message (including attachments, if any) is intended for the use of the individual or entity to which it is addressed and may contain information that is privileged, proprietary , confidential and exempt from disclosure. If you are not the intended recipient, you are notified that any dissemination, distribution or copying of this communication is strictly prohibited. --- Le présent message électronique (y compris les pièces qui y sont annexées, le cas échéant) s'adresse au destinataire indiqué et peut contenir des renseignements de caractère privé ou confidentiel. Si vous n'êtes pas le destinataire de ce document, nous vous signalons qu'il est strictement interdit de le diffuser, de le distribuer ou de le reproduire. - Original Message - From: Hassan Schroeder [EMAIL PROTECTED] To: Tomcat Users List users@tomcat.apache.org Sent: Saturday, December 30, 2006 2:39 PM Subject: Re: session#getId changes during doGet invocation under heavy load On 12/30/06, Peter Coppens [EMAIL PROTECTED] wrote: That said, I am baffled by the fact that some connections take 15minutes. Are you referring to MySQL connection setup time? Or query time? Either way, it certainly doesn't sound like a Tomcat problem... :-) -- Hassan Schroeder [EMAIL PROTECTED] - To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Not quite a tomcat question
Happy New Year All. Does anyone use sessions to temporarily hold confirmation codes for user registrations? I have a setup where when the user registers a random confirmation code is generated and appended to a url which is emailed to the user. The user's registration data is stored in a session with the confirmation code as the key. When they click the confirmation link, the code is used to retrieve the registration information and the registration is done. Some users are having trouble because it seems they're encountering invalidated sessions. I know if the registrations is done in one browser and the link (outlook will open IE) opens up a different browser that would lead to the creation of a different session which obviously wouldn't have the registration data. I have seen implementations that enter the confirmation directly into the database but I don't want to do that since it would mean writing more code to check who's account is activated and who's hasn't, and also might lead to garbage in the database of users who never activated their accounts...Any suggestions? -- talk trash and carry a small stick. PAUL KRUGMAN (NYT)
controling resource and cpu hogging
We have several domains that each have several WAR files deployed. How can misbehaving deployed WAR's be identified and 1. killed off (maybe an issue if they hold onto threads or instance references when undeploy or stop is called) 2. be controlled (ie: throttle/cap a specific domain and/or WAR deployment in CPU consumption). - To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: What a wonderfull world ..
Mark Thomas [EMAIL PROTECTED] wrote in message news:[EMAIL PROTECTED] Martin Gainty wrote: Im still waiting for the usual insults from chuck..then again maybe he took the day off.. Martin, This sort of comment is completely out of line. There is no justification whatsoever for your behaviour on this thread. I expect to see a public apology on this thread from you to Chuck forthwith. Frack, after all Chuck started it. Get a life, and let these two little kiddies get on with their mud fight. Just do what I do and block both of them :). This is the second time I have had to ask you to apologise to Chuck. You ignored my request the last time, I do not expect to be ignored a second time. Mark [EMAIL PROTECTED] This sort of gross over-reaction is a sure sign that you should pass this title on to someone else. Remember that this isn't a cathedral, it's a bazaar. - To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: What a wonderfull world ..
Frack, after all Chuck started it. Get a life, and let these two little kiddies get on with their mud fight. Who started what is debatable but there's no need to continue it -- or invite it as is the case here. --David Bill Barker wrote: Mark Thomas [EMAIL PROTECTED] wrote in message news:[EMAIL PROTECTED] Martin Gainty wrote: Im still waiting for the usual insults from chuck..then again maybe he took the day off.. Martin, This sort of comment is completely out of line. There is no justification whatsoever for your behaviour on this thread. I expect to see a public apology on this thread from you to Chuck forthwith. Frack, after all Chuck started it. Get a life, and let these two little kiddies get on with their mud fight. Just do what I do and block both of them :). This is the second time I have had to ask you to apologise to Chuck. You ignored my request the last time, I do not expect to be ignored a second time. Mark [EMAIL PROTECTED] This sort of gross over-reaction is a sure sign that you should pass this title on to someone else. Remember that this isn't a cathedral, it's a bazaar. - To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
