You are viewing a plain text version of this content. The canonical link for it is here.

Posted to users@tomcat.apache.org by Uw...@t-systems.com on 2011/12/20 14:36:37 UTC

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=login&user=username&pass=

I send it away and because of a wrong pass Variable It returned the following
http://myhost.de/action=login&user=username&errorcode=1

I can repeat that a hundred times and sometime It returns

http://myhost.de/action=login&user=otherusername&errorcode=1

Every other ideas are welcome.

Kind Regards
Uwe

Re: How much connections are handled per thread?

Posted by Pid <pi...@pidster.com>.

On 20/12/2011 13:36, Uwe.Hellmann@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=login&user=username&pass=
> 
> I send it away and because of a wrong pass Variable It returned the following
> http://myhost.de/action=login&user=username&errorcode=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=login&user=otherusername&errorcode=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]

RE: How much connections are handled per thread?

Posted by "Caldarale, Charles R" <Ch...@unisys.com>.

> From: Uwe.Hellmann@t-systems.com [mailto:Uwe.Hellmann@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-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org

AW: AW: How much connections are handled per thread?

Posted by Uw...@t-systems.com.

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:chris@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.Hellmann@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-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org

AW: AW: How much connections are handled per thread?

Posted by Uw...@t-systems.com.

Hello Chris,

Kind regards any have a nice Christmas.

Uwe

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Uwe,

On 12/20/11 11:11 AM, Uwe.Hellmann@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.

> But on the other hand I have to prove that it is not tomcats
> failure which causes this issues. *sigh*

- -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-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org

Re: AW: How much connections are handled per thread?

Posted by Christopher Schultz <ch...@christopherschultz.net>.

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Uwe,

On 12/20/11 11:11 AM, Uwe.Hellmann@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-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org

AW: How much connections are handled per thread?

Posted by Uw...@t-systems.com.

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:tc@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.Hellmann@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-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org


---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org

Re: How much connections are handled per thread?

Posted by Tobias Crefeld <tc...@cataneo.eu>.

Am Tue, 20 Dec 2011 15:52:57 +0100
schrieb Uwe.Hellmann@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-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org

AW: How much connections are handled per thread?

Posted by Uw...@t-systems.com.

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:aw@ice-sa.com]
Gesendet: Dienstag, 20. Dezember 2011 15:47
An: Tomcat Users List
Betreff: Re: How much connections are handled per thread?

Uwe.Hellmann@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-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org

Re: How much connections are handled per thread?

Posted by André Warnier <aw...@ice-sa.com>.

Uwe.Hellmann@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-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org