AW: AW: How much connections are handled per thread?
Hello together, the developers have committed now that indeed there is a library implemented in the application which causes the below discussed error. Something about a filter which uses a static component for URL and the passed username. Just wanted to let you know. Uwe -Ursprüngliche Nachricht- Von: Hellmann, Uwe Gesendet: Donnerstag, 22. Dezember 2011 08:22 An: users@tomcat.apache.org Betreff: AW: AW: How much connections are handled per thread? Hello Chris, you helped me enough with all the infos or hints you and the other persons on this list have provided. I can't provide any code, because I am not allowed to do so. My work is to try to prove that it is not our infrastructure including tomcat which does create this issue. Until now I am not that firm in java-coding so I think searching in the applications code would be useless at least for me and it is not my job. Like I said before you all helped me much, now it is time for the developers to check. Kind regards any have a nice Christmas. Uwe -Ursprüngliche Nachricht- Von: Christopher Schultz [mailto:ch...@christopherschultz.net] Gesendet: Mittwoch, 21. Dezember 2011 16:41 An: Tomcat Users List Betreff: Re: AW: How much connections are handled per thread? -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Uwe, On 12/20/11 11:11 AM, uwe.hellm...@t-systems.com wrote: I tried everything the last half year to convince him to switch to current tomcat or at least to tomcat 6. It was a waste of energy. Tomcat 5.5 will experience EOL on 30 September 2012. So, they have about 9 months to get an upgrade into testing before they are flying without a parachute. Tell them that they can either upgrade while there is support for the older version, or wait until there is essentially no choice (some security bug found that will not be fixed) before making a hasty upgrade. But on the other hand I have to prove that it is not tomcats failure which causes this issues. *sigh* One cannot prove a negative. If Tomcat were exchanging parameter values between requests don't you think the entire world would fall apart? Given that only your webapp appears to be suffering from this problem, the logical conclusion is that the problem is in the webapp. I'm not saying there definitely is NOT a problem with Tomcat, but the odds are against Tomcat being the problem. You ave provided virtually no information across both of your discussion threads other than we issue request to X and get no parameter value somewhere. We can't read your code. We can't read your mind. Given those circumstances, we cannot help you. If you want to send your developers here so they can give us more information, maybe we /can/ help. - -chris -BEGIN PGP SIGNATURE- Version: GnuPG/MacGPG2 v2.0.17 (Darwin) Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk7x/fwACgkQ9CaO5/Lv0PB2vACdF1s7RIodWYCFY9LrbsPAqYG4 ktQAn1/fTYmH2zkY5LiIgnDK+E+iDkRc =ftTS -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: AW: How much connections are handled per thread?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Uwe, On 12/20/11 11:11 AM, uwe.hellm...@t-systems.com wrote: I tried everything the last half year to convince him to switch to current tomcat or at least to tomcat 6. It was a waste of energy. Tomcat 5.5 will experience EOL on 30 September 2012. So, they have about 9 months to get an upgrade into testing before they are flying without a parachute. Tell them that they can either upgrade while there is support for the older version, or wait until there is essentially no choice (some security bug found that will not be fixed) before making a hasty upgrade. But on the other hand I have to prove that it is not tomcats failure which causes this issues. *sigh* One cannot prove a negative. If Tomcat were exchanging parameter values between requests don't you think the entire world would fall apart? Given that only your webapp appears to be suffering from this problem, the logical conclusion is that the problem is in the webapp. I'm not saying there definitely is NOT a problem with Tomcat, but the odds are against Tomcat being the problem. You ave provided virtually no information across both of your discussion threads other than we issue request to X and get no parameter value somewhere. We can't read your code. We can't read your mind. Given those circumstances, we cannot help you. If you want to send your developers here so they can give us more information, maybe we /can/ help. - -chris -BEGIN PGP SIGNATURE- Version: GnuPG/MacGPG2 v2.0.17 (Darwin) Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk7x/fwACgkQ9CaO5/Lv0PB2vACdF1s7RIodWYCFY9LrbsPAqYG4 ktQAn1/fTYmH2zkY5LiIgnDK+E+iDkRc =ftTS -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
AW: AW: How much connections are handled per thread?
Hello Chris, you helped me enough with all the infos or hints you and the other persons on this list have provided. I can't provide any code, because I am not allowed to do so. My work is to try to prove that it is not our infrastructure including tomcat which does create this issue. Until now I am not that firm in java-coding so I think searching in the applications code would be useless at least for me and it is not my job. Like I said before you all helped me much, now it is time for the developers to check. Kind regards any have a nice Christmas. Uwe -Ursprüngliche Nachricht- Von: Christopher Schultz [mailto:ch...@christopherschultz.net] Gesendet: Mittwoch, 21. Dezember 2011 16:41 An: Tomcat Users List Betreff: Re: AW: How much connections are handled per thread? -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Uwe, On 12/20/11 11:11 AM, uwe.hellm...@t-systems.com wrote: I tried everything the last half year to convince him to switch to current tomcat or at least to tomcat 6. It was a waste of energy. Tomcat 5.5 will experience EOL on 30 September 2012. So, they have about 9 months to get an upgrade into testing before they are flying without a parachute. Tell them that they can either upgrade while there is support for the older version, or wait until there is essentially no choice (some security bug found that will not be fixed) before making a hasty upgrade. But on the other hand I have to prove that it is not tomcats failure which causes this issues. *sigh* One cannot prove a negative. If Tomcat were exchanging parameter values between requests don't you think the entire world would fall apart? Given that only your webapp appears to be suffering from this problem, the logical conclusion is that the problem is in the webapp. I'm not saying there definitely is NOT a problem with Tomcat, but the odds are against Tomcat being the problem. You ave provided virtually no information across both of your discussion threads other than we issue request to X and get no parameter value somewhere. We can't read your code. We can't read your mind. Given those circumstances, we cannot help you. If you want to send your developers here so they can give us more information, maybe we /can/ help. - -chris -BEGIN PGP SIGNATURE- Version: GnuPG/MacGPG2 v2.0.17 (Darwin) Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk7x/fwACgkQ9CaO5/Lv0PB2vACdF1s7RIodWYCFY9LrbsPAqYG4 ktQAn1/fTYmH2zkY5LiIgnDK+E+iDkRc =ftTS -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
How much connections are handled per thread?
Hello together, just a short question. Does a single Tomcat thread handle more than one connection at a time? (kind of multiplexing) Is it possible that if there are more connections at a time per thread that there is a bug that a GET variable is exchanged between these connections? An example: I have requested a page http://myhost.de/action=loginuser=usernamepass= I send it away and because of a wrong pass Variable It returned the following http://myhost.de/action=loginuser=usernameerrorcode=1 I can repeat that a hundred times and sometime It returns http://myhost.de/action=loginuser=otherusernameerrorcode=1 Every other ideas are welcome. Kind Regards Uwe
RE: How much connections are handled per thread?
From: uwe.hellm...@t-systems.com [mailto:uwe.hellm...@t-systems.com] Subject: How much connections are handled per thread? Does a single Tomcat thread handle more than one connection at a time? No (discounting the asynch mechanisms). Is it possible that if there are more connections at a time per thread that there is a bug that a GET variable is exchanged between these connections? Since the premise is false, the answer has to be no. This kind of behavior is pretty much always due to errors in the application, such as storing values in variables at the wrong scope (e.g., a request-specific value kept in a servlet instance field). - 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: How much connections are handled per thread?
On 20/12/2011 13:36, uwe.hellm...@t-systems.com wrote: Hello together, just a short question. Does a single Tomcat thread handle more than one connection at a time? (kind of multiplexing) No. Is it possible that if there are more connections at a time per thread that there is a bug that a GET variable is exchanged between these connections? An example: I have requested a page http://myhost.de/action=loginuser=usernamepass= I send it away and because of a wrong pass Variable It returned the following http://myhost.de/action=loginuser=usernameerrorcode=1 The above doesn't make sense to me, can you explain it again please? I can repeat that a hundred times and sometime It returns http://myhost.de/action=loginuser=otherusernameerrorcode=1 A connection is assigned to a thread. A thread may then access a Servlet. Servlet classes are not inherently thread-safe. If I understand your problem correctly (I'm not sure I do) this kind of error usually occurs because the developer has incorrectly stored some data as an instance field in a Servlet (or related subclass) and subsequent threads access the field causing it to mutate before the current thread finishes using it. p Every other ideas are welcome. Kind Regards Uwe -- [key:62590808] signature.asc Description: OpenPGP digital signature
Re: How much connections are handled per thread?
uwe.hellm...@t-systems.com wrote: Hello together, just a short question. Does a single Tomcat thread handle more than one connection at a time? (kind of multiplexing) Essentially, no. One tomcat thread could be handling several successive *requests* on the same connection, one after the other, if KeepAlive is enabled. But one thread will not handle multiple connections at the same time. Is it possible that if there are more connections at a time per thread that there is a bug that a GET variable is exchanged between these connections? You are not saying which version of Tomcat this is, which makes it hard to check if there ever was a bug in Tomcat in that respect. It is far more likely that it is something in your application, which does something which is not thread-safe, and causes data to be in effect shared by various threads. Or, something is accidentally being remembered by a thread which has processed a request from a browser, and is being re-used by the same thread to process a later request from another browser (and another connection). Note that the same thread can /successively/ handle several connections, and that the same browser may be using over time several distinct connections with Tomcat. That is not a contradiction with what I said above. Examples : 1) a browser establishes a connection with tomcat, and sends one request to tomcat over that connection; then it waits for the response. Tomcat allocates one thread to this new connection. The thread processes the request and sends the response. The browser reads the response, and then he goes away and never asks for more. After a while (maybe immediately if there is no KeepAlive), the thread will close the connection and become available again to process a new connection. This new connection could be from the same browser, or not. 2) a browser establishes a connection with tomcat, and sends one request to tomcat over that connection; then it waits for the response. Tomcat allocates one thread to this new connection. The thread processes the request and sends the response. The browser reads the response, and sends another request over the same connection (because KeepAlive is on). The same thread processes the second browser request and responds. This goes on as long as the browser is sending more requests on that connection, until the KeepAlive request limit is reached (maybe never, if there is no limit). When the limit is reached, the thread closes the connection and becomes available again for other connections. If the browser wants to send more requests, it must create a new connection and send these requests over that new connection. At the tomcat level, this would be processed by a new thread (which may by chance be the same as the first time, but that is unlikely). - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
AW: How much connections are handled per thread?
It is Tomcat 5.5.26 summarize all information which I have gathered so far from your answers it looks like a problem which seem to occur trhough a not-thread safe implementation of a class or the whole servlet? If this is the case I get some munition to go the the developers. Thanks for all your help - Uwe -Ursprüngliche Nachricht- Von: André Warnier [mailto:a...@ice-sa.com] Gesendet: Dienstag, 20. Dezember 2011 15:47 An: Tomcat Users List Betreff: Re: How much connections are handled per thread? uwe.hellm...@t-systems.com wrote: Hello together, just a short question. Does a single Tomcat thread handle more than one connection at a time? (kind of multiplexing) Essentially, no. One tomcat thread could be handling several successive *requests* on the same connection, one after the other, if KeepAlive is enabled. But one thread will not handle multiple connections at the same time. Is it possible that if there are more connections at a time per thread that there is a bug that a GET variable is exchanged between these connections? You are not saying which version of Tomcat this is, which makes it hard to check if there ever was a bug in Tomcat in that respect. It is far more likely that it is something in your application, which does something which is not thread-safe, and causes data to be in effect shared by various threads. Or, something is accidentally being remembered by a thread which has processed a request from a browser, and is being re-used by the same thread to process a later request from another browser (and another connection). Note that the same thread can /successively/ handle several connections, and that the same browser may be using over time several distinct connections with Tomcat. That is not a contradiction with what I said above. Examples : 1) a browser establishes a connection with tomcat, and sends one request to tomcat over that connection; then it waits for the response. Tomcat allocates one thread to this new connection. The thread processes the request and sends the response. The browser reads the response, and then he goes away and never asks for more. After a while (maybe immediately if there is no KeepAlive), the thread will close the connection and become available again to process a new connection. This new connection could be from the same browser, or not. 2) a browser establishes a connection with tomcat, and sends one request to tomcat over that connection; then it waits for the response. Tomcat allocates one thread to this new connection. The thread processes the request and sends the response. The browser reads the response, and sends another request over the same connection (because KeepAlive is on). The same thread processes the second browser request and responds. This goes on as long as the browser is sending more requests on that connection, until the KeepAlive request limit is reached (maybe never, if there is no limit). When the limit is reached, the thread closes the connection and becomes available again for other connections. If the browser wants to send more requests, it must create a new connection and send these requests over that new connection. At the tomcat level, this would be processed by a new thread (which may by chance be the same as the first time, but that is unlikely). - 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: How much connections are handled per thread?
Am Tue, 20 Dec 2011 15:52:57 +0100 schrieb uwe.hellm...@t-systems.com: It is Tomcat 5.5.26 [..] If this is the case I get some munition to go the the developers. In my experience this route is an useless approach as long as you run a 4 years old Tomcat and without being able to identify classes that aren't thread-safe. RU, Tobias. - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
AW: How much connections are handled per thread?
Yes you are completely right, but that is not my decision it is the customers. I tried everything the last half year to convince him to switch to current tomcat or at least to tomcat 6. It was a waste of energy. But on the other hand I have to prove that it is not tomcats failure which causes this issues. *sigh* -Ursprüngliche Nachricht- Von: Tobias Crefeld [mailto:t...@cataneo.eu] Gesendet: Dienstag, 20. Dezember 2011 16:56 An: users@tomcat.apache.org Betreff: Re: How much connections are handled per thread? Am Tue, 20 Dec 2011 15:52:57 +0100 schrieb uwe.hellm...@t-systems.com: It is Tomcat 5.5.26 [..] If this is the case I get some munition to go the the developers. In my experience this route is an useless approach as long as you run a 4 years old Tomcat and without being able to identify classes that aren't thread-safe. RU, Tobias. - 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
