RE: Servlet Concurrency Issues
Thanks Chuck, that was exactly the problem. I was under the very poor assumption that a new thread and newly instantiated servlet object was created every time a request was made, instead of all threads working on only one instance of an object. To mimic the desired behavior I've fixed the problem by adding this (implements SingleThreadModel)... public class ServletName implements SingleThreadModel Now it would seem that if several 100 people were to access a servlet that every time the following code was hit by a new thread: PrintWriter out = response.getWriter(); It would direct all output (using out.println()) from all threads to the most recent person to access the servlet. Follow up question: With this in mind, what is the most common method of writing thread safe code? Thank you very much for your help. -Mike -Original Message- From: Caldarale, Charles R [mailto:[EMAIL PROTECTED] Sent: Tuesday, June 07, 2005 1:15 PM To: Tomcat Users List Subject: RE: Servlet Concurrency Issues From: Michael Pasko [mailto:[EMAIL PROTECTED] Subject: Servlet Concurrency Issues I started allowing other users on it, I stumbled on some problems. Basically what happens, when user A submits the form, and then 2 seconds later user B submits the same form. User A stops getting results, and User B receives the output for his request as well as the end of User A's request. Probably not a configuration problem but rather implementation errors in your servlet or some related object (such as the DB connection). There's normally only one copy of the servlet object, and it will be used concurrently by multiple threads. Make sure you're not storing request-specific information in there. - 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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Servlet Concurrency Issues
For thread safe programs 1. Declare all your variables within your method. 2. Do not declare static ( class level ) variables. 3. Pass Parameters from one method to another rather than accessing global variables. Regards Guru -Original Message- From: Michael Pasko [mailto:[EMAIL PROTECTED] Sent: 08 June 2005 13:33 To: 'Tomcat Users List' Subject: RE: Servlet Concurrency Issues Thanks Chuck, that was exactly the problem. I was under the very poor assumption that a new thread and newly instantiated servlet object was created every time a request was made, instead of all threads working on only one instance of an object. To mimic the desired behavior I've fixed the problem by adding this (implements SingleThreadModel)... public class ServletName implements SingleThreadModel Now it would seem that if several 100 people were to access a servlet that every time the following code was hit by a new thread: PrintWriter out = response.getWriter(); It would direct all output (using out.println()) from all threads to the most recent person to access the servlet. Follow up question: With this in mind, what is the most common method of writing thread safe code? Thank you very much for your help. -Mike -Original Message- From: Caldarale, Charles R [mailto:[EMAIL PROTECTED] Sent: Tuesday, June 07, 2005 1:15 PM To: Tomcat Users List Subject: RE: Servlet Concurrency Issues From: Michael Pasko [mailto:[EMAIL PROTECTED] Subject: Servlet Concurrency Issues I started allowing other users on it, I stumbled on some problems. Basically what happens, when user A submits the form, and then 2 seconds later user B submits the same form. User A stops getting results, and User B receives the output for his request as well as the end of User A's request. Probably not a configuration problem but rather implementation errors in your servlet or some related object (such as the DB connection). There's normally only one copy of the servlet object, and it will be used concurrently by multiple threads. Make sure you're not storing request-specific information in there. - 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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - 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]
RE: Servlet Concurrency Issues
From: Michael Pasko [mailto:[EMAIL PROTECTED] To mimic the desired behavior I've fixed the problem by adding this (implements SingleThreadModel)... public class ServletName implements SingleThreadModel Note that SingleThreadModel isn't supported in more recent versions of Tomcat. This may or may not worry you depending on whether you want to move to a more recent version :-). Now it would seem that if several 100 people were to access a servlet that every time the following code was hit by a new thread: PrintWriter out = response.getWriter(); It would direct all output (using out.println()) from all threads to the most recent person to access the servlet. The servlet spec mandates that each concurrent request (which is processed on its own thread) has distinct request and response objects passed in, so response.getWriter() will get the writer for the current thread's response object - which is guaranteed not to be the same as that for any other request that's being processed at the same time. Reading between the lines, by the way, this means that the container may, if it wishes, recycle objects (and indeed threads) between requests. I know Tomcat 5.0 does this. Follow up question: With this in mind, what is the most common method of writing thread safe code? As Guru said, plus a couple of process-related points: - Go through the spec for third-party code that you're using (libraries, servlet containers and the like). Check what guarantees they make about thread-safety, and check what guarantees they make about object uniqueness. If you don't know what the rest of the system provides, you can be in for some surprises. - Test! Jmeter (or some similar multi-threaded load testing tool) is your friend. As Knuth remarked, Beware of the above code; I have only proved it correct, not tried it. Writing solid thread-safe code takes more thinking, and hence more time, than writing single-threaded code; and the likelihood of defects goes up as you now have to think about interactions between threads which may occur at arbitrary times. In a recent project, we bought an 8 CPU box with the slowest processors we could find, simply so that we could load it up with requests fairly trivially and so that it could sit and chug away at our test suite looking for threading issues. We found several... - Peter - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Servlet Concurrency Issues
On 6/8/05, Peter Crowther [EMAIL PROTECTED] wrote: Note that SingleThreadModel isn't supported in more recent versions of Tomcat. This may or may not worry you depending on whether you want to move to a more recent version :-). I've posted already about that: if you don't know about something, please don't make guesses with the tone of someone who knows his stuff, since you'll just end up confusing people. Your statement is completely wrong, STM is fully supported in Tomcat 5.5, with instance pooling for good performance. It's usually much faster than having lots of sync in your servlet, that is. I actually like the feature, personally. The only reason it got removed is because it gave users the impression that no additional syncing was ever needed (which is not the case, as session modification may still be unsafe). -- x Rémy Maucherat Developer Consultant JBoss Group (Europe) SàRL x - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Servlet Concurrency Issues
From: Remy Maucherat [mailto:[EMAIL PROTECTED] Your statement is completely wrong, STM is fully supported in Tomcat 5.5, with instance pooling for good performance. Sorry, Remy - I should have checked rather than relying on memory. - Peter - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Servlet Concurrency Issues
On 6/8/05, Peter Crowther [EMAIL PROTECTED] wrote: From: Remy Maucherat [mailto:[EMAIL PROTECTED] Your statement is completely wrong, STM is fully supported in Tomcat 5.5, with instance pooling for good performance. Sorry, Remy - I should have checked rather than relying on memory. No problem. STM is deprecated in the specification, but support is mandatory (of course, if the container doesn't do pooling, performance will be really bad). I hope it doesn't get removed, since it is sometimes useful (maybe it could be reinstated with a different name). -- x Rémy Maucherat Developer Consultant JBoss Group (Europe) SàRL x - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Servlet Concurrency Issues
Your best bet for understanding multithreading issues is to get a good understanding of the JVM. On 6/8/05, Michael Pasko [EMAIL PROTECTED] wrote: Thanks Chuck, that was exactly the problem. I was under the very poor assumption that a new thread and newly instantiated servlet object was created every time a request was made, instead of all threads working on only one instance of an object. To mimic the desired behavior I've fixed the problem by adding this (implements SingleThreadModel)... public class ServletName implements SingleThreadModel Now it would seem that if several 100 people were to access a servlet that every time the following code was hit by a new thread: PrintWriter out = response.getWriter(); It would direct all output (using out.println()) from all threads to the most recent person to access the servlet. Follow up question: With this in mind, what is the most common method of writing thread safe code? Thank you very much for your help. -Mike -Original Message- From: Caldarale, Charles R [mailto:[EMAIL PROTECTED] Sent: Tuesday, June 07, 2005 1:15 PM To: Tomcat Users List Subject: RE: Servlet Concurrency Issues From: Michael Pasko [mailto:[EMAIL PROTECTED] Subject: Servlet Concurrency Issues I started allowing other users on it, I stumbled on some problems. Basically what happens, when user A submits the form, and then 2 seconds later user B submits the same form. User A stops getting results, and User B receives the output for his request as well as the end of User A's request. Probably not a configuration problem but rather implementation errors in your servlet or some related object (such as the DB connection). There's normally only one copy of the servlet object, and it will be used concurrently by multiple threads. Make sure you're not storing request-specific information in there. - 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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- You can lead a horse to water but you cannot make it float on its back. ~Dakota Jack~ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Servlet Concurrency Issues
On 6/8/05, Dakota Jack [EMAIL PROTECTED] wrote: Your best bet for understanding multithreading issues is to get a good understanding of the JVM. Can you recommend one ? -- rgds Anto Paul - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Servlet Concurrency Issues
hihi all, does Tomcat 5.5.x handle this instance pooling transparently for objects implementing STM? do i need to configure Tomcat to turn on this feature? tia, woodchuck --- Remy Maucherat [EMAIL PROTECTED] wrote: Your statement is completely wrong, STM is fully supported in Tomcat 5.5, with instance pooling for good performance. It's usually much faster than having lots of sync in your servlet, that is. I actually like the feature, personally. The only reason it got removed is because it gave users the impression that no additional syncing was ever needed (which is not the case, as session modification may still be unsafe). __ Discover Yahoo! Stay in touch with email, IM, photo sharing and more. Check it out! http://discover.yahoo.com/stayintouch.html - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Servlet Concurrency Issues
I've recently developed a servlet that connects to an AS/400, and returns results off an sql query based off criteria submitted by a form. I've had pretty much exclusive use of the Tomcat server during development, but when I started allowing other users on it, I stumbled on some problems. Basically what happens, when user A submits the form, and then 2 seconds later user B submits the same form. User A stops getting results, and User B receives the output for his request as well as the end of User A's request. User A is on a different computer than B and both have different session ID's. I'm sure this is a configuration error on my part, but would appreciate a direction on where to look. PS - I create a session if it doesn't exist, and store the username and DB connection in it. (Will use JNDI later) I'm using Tomcat 5.5.7
RE: Servlet Concurrency Issues
From: Michael Pasko [mailto:[EMAIL PROTECTED] Subject: Servlet Concurrency Issues I started allowing other users on it, I stumbled on some problems. Basically what happens, when user A submits the form, and then 2 seconds later user B submits the same form. User A stops getting results, and User B receives the output for his request as well as the end of User A's request. Probably not a configuration problem but rather implementation errors in your servlet or some related object (such as the DB connection). There's normally only one copy of the servlet object, and it will be used concurrently by multiple threads. Make sure you're not storing request-specific information in there. - 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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Servlet Concurrency Issues
You're probably using instance properties on the servlet object. George Sexton MH Software, Inc. http://www.mhsoftware.com/ Voice: 303 438 9585 -Original Message- From: Michael Pasko [mailto:[EMAIL PROTECTED] Sent: Tuesday, June 07, 2005 12:09 PM To: 'tomcat-user@jakarta.apache.org' Subject: Servlet Concurrency Issues I've recently developed a servlet that connects to an AS/400, and returns results off an sql query based off criteria submitted by a form. I've had pretty much exclusive use of the Tomcat server during development, but when I started allowing other users on it, I stumbled on some problems. Basically what happens, when user A submits the form, and then 2 seconds later user B submits the same form. User A stops getting results, and User B receives the output for his request as well as the end of User A's request. User A is on a different computer than B and both have different session ID's. I'm sure this is a configuration error on my part, but would appreciate a direction on where to look. PS - I create a session if it doesn't exist, and store the username and DB connection in it. (Will use JNDI later) I'm using Tomcat 5.5.7 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
