Re: Apache tomcat concurrency issue
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Migual Angel, On 11/10/16 5:51 AM, Roldan, Miguel Angel [Global Data & Content] wrote: > Thanks for your help. After a lot of tests we finally realized it > was related with having tomcat configured to recycle requests and > using apache velocity. I use Apache Velocity and have no such concurrency issues. Note that "recycling requests" doesn't mean what you might think it does: in Tomcat, "recycling request facades" means that the facades are discarded . > We modify the configuration RECYCLE_FACADES setting it to true and > the problem disappear. Then the problem is with your application retaining references to request and/or response objects after the request should have completed. 99% of the time this is the reason for reports of the kind you gave. This is not a bug in Tomcat, nor is it a bug in Velocity. It's a bug in your application. - -chris > -Original Message- From: Christopher Schultz > [mailto:ch...@christopherschultz.net] Sent: viernes, 04 de > noviembre de 2016 23:26 To: Tomcat Users List > Subject: Re: Apache tomcat concurrency > issue > > Miguel Angel, > > On 11/3/16 12:52 PM, Roldan, Miguel Angel [Global Data & Content] > wrote: > > (Moving this up to the top:) > >> Httpd apache server on the front-end v. 2.2 connected to apache >> tomcat using AJP connector 1.3 > >> Apache tomcat 7.0.56 > > Thanks. > >> We are facing some random concurrency issues in our tomcat >> environments. > > >> 1. We have a web application deployed on Tomcat that handles >> requests from browsers (AJAX and non-AJAX) and also from an >> applet. > >> 2. The requests send by the browser and always gets and >> posts (with application/x-www-form-urlencoded format) > >> 3. The requests made by the applet are compressed and send >> in binary, they are handled by a different Servlet that reads >> the content by executing request.getInputStream(). > > Are you compressing and sending a big blob called "data" or > something similar? Or are you sending multiple parameters > separately compressed? > >> 4. Randomly, mainly after opening the applet from the >> current session or in another session executed on the same server >> (which send some requests in parallel) requests send from the >> browser arrives to the server with an empty >> request.getParameterMap() > > If you are calling request.getInputStream, then you will never get > anything in the parameter map. If your code consumes the request > body in a POST, then Tomcat cannot parse it again. > >> 5. We have reviewed that the request was well formed when it >> leaves the browser and also we are able to monitor it with TCP >> Dump and see that arrives correctly to tomcat. > > Good. > >> 6. We have introduced a filter on the first position of the >> filter chain: org.apache.catalina.filters.RequestDumperFilter >> and we have validated that at this point we have already lost all >> of the parameters > > Good thinking. Are you SURE it's the first filter in the chain? We > aware that the RequestDumperValve will rob the data from your > applicatio n. > >> 7. If we try to execute the request.getInputStream() for >> this problematic requests what we see is that the byte array >> that returns belongs to another request made before to the >> server. > > Obviously, that shouldn't happen. > >> 8. If we re-submit the same request after, it works fine. >> They don't have any kind of special character or exceed a >> certain length. > >> 9. Environment configuration: > > >> O.S. - Oracle linux > > > >> 10. Sometimes we are able to reproduce the issue on a >> eclipse-tomcat environment using http connector and we have >> validated that the flag used by the class >> org.apache.catalina.connector.Request parametersParsed is set to >> true. > > > >> Do you have any kind of suggestions on how to further >> investigate the issue? > > Are you able to re-test with an updated version of Tomcat 7? > Current version is 7.0.72. Your version is ~2 years old. > > Can you post your configuration? > > Thoughts about what might be happening: > > 1. Application concurrency/request-object retention bug 2. > maxPostSize value too low -- Tomcat is rejecting the request in a > way unexpected by the application 3. Edge case/bug in Tomcat that > has been fixed in a more-recent version? > > -chris > > ---
Re: Apache tomcat concurrency issue
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Miguel Angel, On 11/3/16 12:52 PM, Roldan, Miguel Angel [Global Data & Content] wrote: (Moving this up to the top:) > Httpd apache server on the front-end v. 2.2 connected to apache > tomcat using AJP connector 1.3 > > Apache tomcat 7.0.56 Thanks. > We are facing some random concurrency issues in our tomcat > environments. > > > 1. We have a web application deployed on Tomcat that handles > requests from browsers (AJAX and non-AJAX) and also from an > applet. > > 2. The requests send by the browser and always gets and posts > (with application/x-www-form-urlencoded format) > > 3. The requests made by the applet are compressed and send in > binary, they are handled by a different Servlet that reads the > content by executing request.getInputStream(). Are you compressing and sending a big blob called "data" or something similar? Or are you sending multiple parameters separately compressed? > 4. Randomly, mainly after opening the applet from the current > session or in another session executed on the same server (which > send some requests in parallel) requests send from the browser > arrives to the server with an empty request.getParameterMap() If you are calling request.getInputStream, then you will never get anything in the parameter map. If your code consumes the request body in a POST, then Tomcat cannot parse it again. > 5. We have reviewed that the request was well formed when it > leaves the browser and also we are able to monitor it with TCP Dump > and see that arrives correctly to tomcat. Good. > 6. We have introduced a filter on the first position of the > filter chain: org.apache.catalina.filters.RequestDumperFilter and > we have validated that at this point we have already lost all of > the parameters Good thinking. Are you SURE it's the first filter in the chain? We aware that the RequestDumperValve will rob the data from your applicatio n. > 7. If we try to execute the request.getInputStream() for this > problematic requests what we see is that the byte array that > returns belongs to another request made before to the server. Obviously, that shouldn't happen. > 8. If we re-submit the same request after, it works fine. They > don't have any kind of special character or exceed a certain > length. > > 9. Environment configuration: > > > O.S. - Oracle linux > > > > 10. Sometimes we are able to reproduce the issue on a > eclipse-tomcat environment using http connector and we have > validated that the flag used by the class > org.apache.catalina.connector.Request parametersParsed is set to > true. > > > > Do you have any kind of suggestions on how to further investigate > the issue? Are you able to re-test with an updated version of Tomcat 7? Current version is 7.0.72. Your version is ~2 years old. Can you post your configuration? Thoughts about what might be happening: 1. Application concurrency/request-object retention bug 2. maxPostSize value too low -- Tomcat is rejecting the request in a way unexpected by the application 3. Edge case/bug in Tomcat that has been fixed in a more-recent version? - -chris -BEGIN PGP SIGNATURE- Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBCAAGBQJYHQsTAAoJEBzwKT+lPKRYUMgP/3vpg67S/g8jGkdNbWz6PhjP /MJjzV8RnThF+NladYyQrJLjw+29eQ9MiQozf4YaXVC5NOfiYKy0kKz1QPw+Cz8q Mqc0ExXYkvjX1/0Op2mlkA2GY9OU976VrSFxE0yFqUomWswtar/MCmbB++fqGWdS 8xE8y62ZuW1gi0EoXU/9UiTqz3AI+ni6vxvXOFuTbzES/qudwLe5ojShHVA8DiIB zityp3gXYvTU0QDPYcVbJBP1PNGGlgqhW0cT4jlujztb8pOieLSpMYb1o1jY00SX Z2E781GCl63H1avQFr4tNNsRkDn7J2Xlsg0X7ixDyeJ3RDrNG+2WjYs8XoQ8WSEI pQ1JSCKa8EVjY87jQFocsI/DH3y9LhiMqo+80EWG3tE932JiTcqxfi0ZamPWF0qn w/fotttCaH638QWQBc4eQErDEFsvBDi0uDP0+lergEptjvduovXmjYTmD0SRtoPM BdmZNGXdIpQtldhvnP0LwhrnKlryVw+Zo5MB3a2IelwxLAAH8BmDYAyRmKc3RTDH lPa9gKWLPdq5NrTKpXqSSbrq0UriEiRpZ66XyBe5IKFc1tX+AvJtChj0ss2wQdKY 6WMPoJsKAiUXii6eYJ9uVSEDfvF1LJr31VyQENHOvN7elRxkvo963XQ6esOTSAbd jEqvpcdkgyz9dvo240kT =Ycbm -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Apache tomcat concurrency issue
Hi, We are facing some random concurrency issues in our tomcat environments. 1. We have a web application deployed on Tomcat that handles requests from browsers (AJAX and non-AJAX) and also from an applet. 2. The requests send by the browser and always gets and posts (with application/x-www-form-urlencoded format) 3. The requests made by the applet are compressed and send in binary, they are handled by a different Servlet that reads the content by executing request.getInputStream(). 4. Randomly, mainly after opening the applet from the current session or in another session executed on the same server (which send some requests in parallel) requests send from the browser arrives to the server with an empty request.getParameterMap() 5. We have reviewed that the request was well formed when it leaves the browser and also we are able to monitor it with TCP Dump and see that arrives correctly to tomcat. 6. We have introduced a filter on the first position of the filter chain: org.apache.catalina.filters.RequestDumperFilter and we have validated that at this point we have already lost all of the parameters 7. If we try to execute the request.getInputStream() for this problematic requests what we see is that the byte array that returns belongs to another request made before to the server. 8. If we re-submit the same request after, it works fine. They don't have any kind of special character or exceed a certain length. 9. Environment configuration: Httpd apache server on the front-end v. 2.2 connected to apache tomcat using AJP connector 1.3 Apache tomcat 7.0.56 O.S. - Oracle linux 10. Sometimes we are able to reproduce the issue on a eclipse-tomcat environment using http connector and we have validated that the flag used by the class org.apache.catalina.connector.Request parametersParsed is set to true. Do you have any kind of suggestions on how to further investigate the issue? Many thanks and regards, Miguel A. Roldán. "This e-mail, any associated files and the information contained in them are confidential and is intended for the addressee(s) only. If you have received this message in error please notify the originator and delete the email immediately. The unauthorised use, disclosure, copying or alteration of this message is strictly forbidden. E-mails to and from the company are monitored for operational reasons and in accordance with lawful business practices. Any opinions expressed are those of the individual and do not necessarily represent the views of the company. The company does not conclude contracts by email and all negotiations are subject to contract. We make every effort to maintain our network free from computer viruses but accept no responsibility for any viruses which might be transferred by this e-mail."
Re: Tomcat Concurrency
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Vicky, On 7/17/13 1:39 AM, vicky b wrote: > Just out of curiosity can you please let me know if there are 10 > clients who access 10 different browsers and make request at the > same time what is the expected output If they really all make requests at once (that is, the server receives 100 simultaneous requests), then I would expect to see: Start thread (x 100) End thread (x 100) If the browser is only making 2 (or 4, or 6) connections simultaneously, then you will see an odd pattern of Start (x 20 - or 40 or 60) followed by the same number of "End" and then another batch. After the first "Start" everything is non-deterministic and you may see interleaved "End" and "Start" depending on how quickly the response gets back to each client, how fast the browser makes the next request, etc. - -chris -BEGIN PGP SIGNATURE- Version: GnuPG/MacGPG2 v2.0.17 (Darwin) Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBCAAGBQJR5rAwAAoJEBzwKT+lPKRYfpsQAIx8Ku8MavTfCIHo/WesKZ+K 0VoVZNzyJ2JA1zEyFzQolUirGRJAelWMv/4opcfkgRG5ynhGMJ+PsVyh1jP4ProF MLQ3mzSAZpJYCv1xaimhH5lZdY827tPmZjKQTlWEqNSR4zbeZlAMpz8aX8kZO5CJ uWwjaBFOhzNp0fmxCiiuwBqRB3+n/ToQKMU1Niyhg2VZq54fg276p3++zfnfX9+f 1y7WXHZz3vbqjIzcZRIQ09UhV9ug9hZW7f+ErmLB6IQ9FooczuXKBiEC6BcEyrXr ivWtMhuJHm0FY8gOkGiyZ6bHlvXGdUmmsC+GWnziBX83d8zQs53nMNpX4iMGjjCS U0Wuz6hY335kv6F7qdUMXa19UtnU+TZGIjY0v93ao0KcdGxQfaHOYLFz6auqyhNI dA4WkkPVRjeX3yJwN7+x1OYuM9iIt2KpAsIOcQF0jiA3SXkfdA+Ra4iS27Cump1L t61rL87GWcY12H4XsQsshR5A4K47MNoamfgxqV4txehaggVi/KBjEp5IPTE+NPWL cy0wFt32hHb4IoiJfvCTYMIB4+RJjYeJbZ/4kgtlHe8zImUXo6T+q6UOJQYQ/ssL yW3jv4zbBzCuJZx4sGAaUtAN5B73GvHq7xaPs81fU5W7QDIJHyZD9lpMCax3Ml0h 2oxJc7uB0loZnkI6rRIx =3zxH -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Tomcat Concurrency
HI All,
Just out of curiosity can you please let me know if there are 10 clients
who access 10 different browsers and make request at the same time what is
the expected output
On Tue, Jul 16, 2013 at 10:14 PM, Christopher Schultz <
ch...@christopherschultz.net> wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA256
>
> Konstantin,
>
> On 7/15/13 6:38 PM, Konstantin Kolinko wrote:
> > 2013/7/16 Mark Haroldson :
> >> Hello;
> >>
> >>
> >>
> >> I am running a tomcat 6 webapp using Jersey and I am running into
> >> a concurrency issue. When there are multiple concurrent
> >> connections to tomcat only one or two are processed concurrently.
> >> I have increased the maxThreads on the connector and now can see
> >> the requests being processed by different threads however I
> >> still on observe one or two threads running concurrently.
> >>
> >>
> >>
> >> Example:
> >>
> >> Given the following servlet;
> >>
> >>
> >>
> >> Servlet()
> >>
> >> {
> >>
> >> Output("Start thread");
> >>
> >> Thread.sleep(2);
> >>
> >> Output("End thread")
> >>
> >> }
> >>
> >>
> >>
> >> I would expect the following output
> >>
> >>
> >>
> >> Start Thread
> >>
> >> Start Thread
> >>
> >> Start Thread
> >>
> >> Start Thread
> >>
> >> End Thread
> >>
> >> End Thread
> >>
> >> End Thread
> >>
> >> End Thread
> >>
> >>
> >>
> >> Instead I see
> >>
> >> Start Thread
> >>
> >> Start Thread
> >>
> >> End Thread
> >>
> >> End Thread
> >>
> >> Start Thread
> >>
> >> End Thread
> >>
> >> Start Thread
> >>
> >> End Thread
> >>
> >>
> >>
> >> What are the factors that control thread concurrency in Tomcat?
> >> Has anyone seen behavior like this before? Should I expect a high
> >> number of concurrent threads or does java/tomcat gate access to
> >> the servlet?
> >>
> >
> > Looking at a crystal ball I would guess that your client is a web
> > browser. A well-behaving browser creates no more than 2
> > simultaneous connections to the same host (a limitation recommended
> > by the HTTP specification).
>
> No longer true. Firefox and Chrome default to 6 per server:
> http://kb.mozillazine.org/Network.http.max-connections-per-server
> http://code.google.com/p/chromium/issues/detail?id=12066
>
> > A Tomcat can certainly serve more than 2 clients simultaneously. It
> > is possible to mis-configure it or create a servlet that serves no
> > more than 1 client, but you must be creative (in a newbie way) to
> > do so.
> >
> > Without seeing your actual configuration and your actual code it
> > is impossible to provide any review.
> >
> > If congestion were at Tomcat side, as when several threads are
> > waiting for the same resource, it would be easy to spot the place
> > by taking a pair of thread dumps (see wiki -> FAQ ->
> > Troubleshooting).
>
> Mark, you should probably print the thread id when doing your
> printlns. That will help you see what is going on. Also, you might
> want to try making more than 4 connections. What client are you using?
>
> - -chris
> -BEGIN PGP SIGNATURE-
> Version: GnuPG/MacGPG2 v2.0.17 (Darwin)
> Comment: GPGTools - http://gpgtools.org
> Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
>
> iQIcBAEBCAAGBQJR5XhVAAoJEBzwKT+lPKRY00wP/3tOIEuEsw+4wdtZhnGYg+aI
> nQj82y7wakuLBYHKDstl/EoEAqKtLoV/hM2nWyctpylkRlZs5oj8fPVEb6xINf4r
> sqqJIwAFGomMod7H+TrQsXa4Tf6v1579iGGAPg4HgVw9MebzYz1y9eFeJ6BeODNw
> /eapZyCeQFFP3CmFQIyyvYk060EqQnaefo8wTMYVc+UZ59zPvq9NwaigerCUezYG
> nwq/GqcqRjdI+xUNkiCraldPVt7amBrUSeZsh2pvYzHvaAuzokaqHMo2kcpixyDf
> kuTwCOdZHUaMsMsHyfh5b6jGNR06DV1djRNJF46jArL4DMCh9NS/H4UgACA1PgAb
> OcW+YOn4lBzzR0lHfx3opitzn7d1i7s6NMwA7djwHRma+XusuMiZLUPahsq3/tXk
> +zwGPiAKyxMb9U68hSZSzSbrEVjdeuyfUo8RKxFvX6RGIK8PcPpkZwOYyzMjuk6u
> rVyxuSB5Ody4slGOAR/3jo6egTe6TXzqeXkL+Zlq7M5SVFVjUZlzmhc7jnb7wqBl
> ZAXIV6hJmDPek+cgsaKi990KRYeWSqtU8W33WR21hgVZBsavJ0uz7wDNaEoPo4Zs
> smA2rMVLA6yWFfOM7oaCJs0UwIfY/N2PNYmVmO8RjUzFT8533GHMKlR/oCAVsnrJ
> u8UNSi9fglS5pelSMX4Z
> =Punl
> -END PGP SIGNATURE-
>
> -
> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: users-h...@tomcat.apache.org
>
>
--
*Thanks & Regards
Vickyb
*
Re: Tomcat Concurrency
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
Konstantin,
On 7/15/13 6:38 PM, Konstantin Kolinko wrote:
> 2013/7/16 Mark Haroldson :
>> Hello;
>>
>>
>>
>> I am running a tomcat 6 webapp using Jersey and I am running into
>> a concurrency issue. When there are multiple concurrent
>> connections to tomcat only one or two are processed concurrently.
>> I have increased the maxThreads on the connector and now can see
>> the requests being processed by different threads however I
>> still on observe one or two threads running concurrently.
>>
>>
>>
>> Example:
>>
>> Given the following servlet;
>>
>>
>>
>> Servlet()
>>
>> {
>>
>> Output("Start thread");
>>
>> Thread.sleep(2);
>>
>> Output("End thread")
>>
>> }
>>
>>
>>
>> I would expect the following output
>>
>>
>>
>> Start Thread
>>
>> Start Thread
>>
>> Start Thread
>>
>> Start Thread
>>
>> End Thread
>>
>> End Thread
>>
>> End Thread
>>
>> End Thread
>>
>>
>>
>> Instead I see
>>
>> Start Thread
>>
>> Start Thread
>>
>> End Thread
>>
>> End Thread
>>
>> Start Thread
>>
>> End Thread
>>
>> Start Thread
>>
>> End Thread
>>
>>
>>
>> What are the factors that control thread concurrency in Tomcat?
>> Has anyone seen behavior like this before? Should I expect a high
>> number of concurrent threads or does java/tomcat gate access to
>> the servlet?
>>
>
> Looking at a crystal ball I would guess that your client is a web
> browser. A well-behaving browser creates no more than 2
> simultaneous connections to the same host (a limitation recommended
> by the HTTP specification).
No longer true. Firefox and Chrome default to 6 per server:
http://kb.mozillazine.org/Network.http.max-connections-per-server
http://code.google.com/p/chromium/issues/detail?id=12066
> A Tomcat can certainly serve more than 2 clients simultaneously. It
> is possible to mis-configure it or create a servlet that serves no
> more than 1 client, but you must be creative (in a newbie way) to
> do so.
>
> Without seeing your actual configuration and your actual code it
> is impossible to provide any review.
>
> If congestion were at Tomcat side, as when several threads are
> waiting for the same resource, it would be easy to spot the place
> by taking a pair of thread dumps (see wiki -> FAQ ->
> Troubleshooting).
Mark, you should probably print the thread id when doing your
printlns. That will help you see what is going on. Also, you might
want to try making more than 4 connections. What client are you using?
- -chris
-BEGIN PGP SIGNATURE-
Version: GnuPG/MacGPG2 v2.0.17 (Darwin)
Comment: GPGTools - http://gpgtools.org
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
iQIcBAEBCAAGBQJR5XhVAAoJEBzwKT+lPKRY00wP/3tOIEuEsw+4wdtZhnGYg+aI
nQj82y7wakuLBYHKDstl/EoEAqKtLoV/hM2nWyctpylkRlZs5oj8fPVEb6xINf4r
sqqJIwAFGomMod7H+TrQsXa4Tf6v1579iGGAPg4HgVw9MebzYz1y9eFeJ6BeODNw
/eapZyCeQFFP3CmFQIyyvYk060EqQnaefo8wTMYVc+UZ59zPvq9NwaigerCUezYG
nwq/GqcqRjdI+xUNkiCraldPVt7amBrUSeZsh2pvYzHvaAuzokaqHMo2kcpixyDf
kuTwCOdZHUaMsMsHyfh5b6jGNR06DV1djRNJF46jArL4DMCh9NS/H4UgACA1PgAb
OcW+YOn4lBzzR0lHfx3opitzn7d1i7s6NMwA7djwHRma+XusuMiZLUPahsq3/tXk
+zwGPiAKyxMb9U68hSZSzSbrEVjdeuyfUo8RKxFvX6RGIK8PcPpkZwOYyzMjuk6u
rVyxuSB5Ody4slGOAR/3jo6egTe6TXzqeXkL+Zlq7M5SVFVjUZlzmhc7jnb7wqBl
ZAXIV6hJmDPek+cgsaKi990KRYeWSqtU8W33WR21hgVZBsavJ0uz7wDNaEoPo4Zs
smA2rMVLA6yWFfOM7oaCJs0UwIfY/N2PNYmVmO8RjUzFT8533GHMKlR/oCAVsnrJ
u8UNSi9fglS5pelSMX4Z
=Punl
-END PGP SIGNATURE-
-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
RE: Tomcat Concurrency
You are correct. I am not using a web browser but a .net class
(HttpWebRequest) that was performing the same function that you described.
For those that are keeping score you just need to set the "ConnectionLimit"
property on HttpWebRequest's service point to a value other than two.
Thanks for the response
Mark
-Original Message-
From: Konstantin Kolinko [mailto:knst.koli...@gmail.com]
Sent: Monday, July 15, 2013 3:39 PM
To: Tomcat Users List
Subject: Re: Tomcat Concurrency
2013/7/16 Mark Haroldson :
> Hello;
>
>
>
> I am running a tomcat 6 webapp using Jersey and I am running into a
> concurrency issue. When there are multiple concurrent connections to
> tomcat only one or two are processed concurrently. I have increased
> the maxThreads on the connector and now can see the requests being
> processed by different threads however I still on observe one or two
threads running concurrently.
>
>
>
> Example:
>
> Given the following servlet;
>
>
>
> Servlet()
>
> {
>
> Output("Start thread");
>
> Thread.sleep(2);
>
> Output("End thread")
>
> }
>
>
>
> I would expect the following output
>
>
>
> Start Thread
>
> Start Thread
>
> Start Thread
>
> Start Thread
>
> End Thread
>
> End Thread
>
> End Thread
>
> End Thread
>
>
>
> Instead I see
>
> Start Thread
>
> Start Thread
>
> End Thread
>
> End Thread
>
> Start Thread
>
> End Thread
>
> Start Thread
>
> End Thread
>
>
>
> What are the factors that control thread concurrency in Tomcat? Has
> anyone seen behavior like this before? Should I expect a high number
> of concurrent threads or does java/tomcat gate access to the servlet?
>
Looking at a crystal ball I would guess that your client is a web browser. A
well-behaving browser creates no more than 2 simultaneous connections to the
same host (a limitation recommended by the HTTP specification).
A Tomcat can certainly serve more than 2 clients simultaneously. It is
possible to mis-configure it or create a servlet that serves no more than 1
client, but you must be creative (in a newbie way) to do so.
Without seeing your actual configuration and your actual code it is
impossible to provide any review.
If congestion were at Tomcat side, as when several threads are waiting for
the same resource, it would be easy to spot the place by taking a pair of
thread dumps (see wiki -> FAQ -> Troubleshooting).
Best regards,
Konstantin Kolinko
-
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: Tomcat Concurrency
Hi,
-Original-Nachricht-
> Von: Mark Haroldson
> An:
> Example:
>
> Given the following servlet;
>
>
>
> Servlet()
>
> {
>
> Output("Start thread");
>
> Thread.sleep(2);
>
> Output("End thread")
>
> }
>
>
>
> I would expect the following output
>
>
>
> Start Thread
>
> Start Thread
>
> Start Thread
>
> Start Thread
>
> End Thread
>
> End Thread
>
> End Thread
>
> End Thread
>
>
>
> Instead I see
>
> Start Thread
>
> Start Thread
>
> End Thread
>
> End Thread
>
> Start Thread
>
> End Thread
>
> Start Thread
>
> End Thread
>
>
>
> What are the factors that control thread concurrency in Tomcat? Has
> anyone seen behavior like this before? Should I expect a high number
> of concurrent threads or does java/tomcat gate access to the servlet?
Are you testing this with a Browser? If so, then I would guess the browser only
uses 1 TCP connection to send all requests. For example, Firefox and Chrome
open only one TCP connection and send the requests sequentially if I open
multiple tabs with the same URL (they wait for the 1st request to finish before
they send the second request). In this case I see an output like this:
Start Thread
End Thread
Start Thread
End Thread
Start Thread
End Thread
However, If I use IE10 on Win8, it will open multiple TCP connections and send
the requests concurrently. The output will look like this:
Start Thread
Start Thread
Start Thread
End Thread
End Thread
End Thread
Regards,
Konstantin Preißer
-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Tomcat Concurrency
2013/7/16 Mark Haroldson :
> Hello;
>
>
>
> I am running a tomcat 6 webapp using Jersey and I am running into a
> concurrency issue. When there are multiple concurrent connections to tomcat
> only one or two are processed concurrently. I have increased the maxThreads
> on the connector and now can see the requests being processed by different
> threads however I still on observe one or two threads running concurrently.
>
>
>
> Example:
>
> Given the following servlet;
>
>
>
> Servlet()
>
> {
>
> Output("Start thread");
>
> Thread.sleep(2);
>
> Output("End thread")
>
> }
>
>
>
> I would expect the following output
>
>
>
> Start Thread
>
> Start Thread
>
> Start Thread
>
> Start Thread
>
> End Thread
>
> End Thread
>
> End Thread
>
> End Thread
>
>
>
> Instead I see
>
> Start Thread
>
> Start Thread
>
> End Thread
>
> End Thread
>
> Start Thread
>
> End Thread
>
> Start Thread
>
> End Thread
>
>
>
> What are the factors that control thread concurrency in Tomcat? Has anyone
> seen behavior like this before? Should I expect a high number of concurrent
> threads or does java/tomcat gate access to the servlet?
>
Looking at a crystal ball I would guess that your client is a web
browser. A well-behaving browser creates no more than 2 simultaneous
connections to the same host (a limitation recommended by the HTTP
specification).
A Tomcat can certainly serve more than 2 clients simultaneously. It is
possible to mis-configure it or create a servlet that serves no more
than 1 client, but you must be creative (in a newbie way) to do so.
Without seeing your actual configuration and your actual code it is
impossible to provide any review.
If congestion were at Tomcat side, as when several threads are waiting
for the same resource, it would be easy to spot the place by taking a
pair of thread dumps (see wiki -> FAQ -> Troubleshooting).
Best regards,
Konstantin Kolinko
-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
Tomcat Concurrency
Hello;
I am running a tomcat 6 webapp using Jersey and I am running into a
concurrency issue. When there are multiple concurrent connections to tomcat
only one or two are processed concurrently. I have increased the maxThreads
on the connector and now can see the requests being processed by different
threads however I still on observe one or two threads running concurrently.
Example:
Given the following servlet;
Servlet()
{
Output("Start thread");
Thread.sleep(2);
Output("End thread")
}
I would expect the following output
Start Thread
Start Thread
Start Thread
Start Thread
End Thread
End Thread
End Thread
End Thread
Instead I see
Start Thread
Start Thread
End Thread
End Thread
Start Thread
End Thread
Start Thread
End Thread
What are the factors that control thread concurrency in Tomcat? Has anyone
seen behavior like this before? Should I expect a high number of concurrent
threads or does java/tomcat gate access to the servlet?
Thanks in advance
Mark
