• Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other Pie Elite all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Jeanne Boyarsky
  • Ron McLeod
  • Paul Clapham
  • Liutauras Vilda
Sheriffs:
  • paul wheaton
  • Rob Spoor
  • Devaka Cooray
Saloon Keepers:
  • Stephan van Hulst
  • Tim Holloway
  • Carey Brown
  • Frits Walraven
  • Tim Moores
Bartenders:
  • Mikalai Zaikin

need help understanding connector attributes

 
Greenhorn
Posts: 18
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Hi all,

So I am trying to understand how the tomcat connector settings work. I am doing this to test some scalabiltiy and trying to determine how an app will work under certain circumnstatnces:

I have a servlet that takes a request, and does some fake processing for 5 seconds, and then returns a response.

I have another java app that launches a bunch of threads that hit the above servlet.

Here is my current xml:

<Connector port="8080" protocol="HTTP/1.1"
connectionTimeout="20000"
redirectPort="8443"
maxThreads="1"
maxKeepAliveRequests = "1"
acceptCount ="1"
minSpareThreads ="1"
maxSpareThreads ="1" />

Since I have maxthreads and acceptCount as one, I would expect that the servlet would not be able to service requests beyond one or two at a time. But, I am able to create about 30 threads that simultaneously hit the servlet. Though it does go pretty slow, most of the requests do not get back any errors. Tomcat is eventually able to service the requests. I would expect that tomact would refuse the connections, and it would appear to the client that server is down. Is tomcat buffering things somewhere? Is there another setting I should look into.

Thanks for your help,

-Adam





 
Ranch Hand
Posts: 470
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

adam spline wrote:I am able to create about 30 threads that simultaneously hit the servlet. Though it does go pretty slow, most of the requests do not get back any errors. Tomcat is eventually able to service the requests. I would expect that tomact would refuse the connections, and it would appear to the client that server is down. Is tomcat buffering things somewhere? Is there another setting I should look into.



How do you define "simultaneously"? For example if it takes for thread 0.1 second to serve a request, then tomcat can handle 10 request per second with your configuration.
 
adam spline
Greenhorn
Posts: 18
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
to clarify a bit about what I meant by simultaneously.

I have a client app that launches a bunch of threads. Those threads make a url connection to my servlet. When the servlet receives the request it does a bunch of fake work (for about 5 seconds) before returning a response. So, if there are 30 client threads which have sent a request to the servlet... there would be 30 servlet threads that are occupied (for around 5 seconds each).

So, if I have 30 client threads and atleast 30 maxThreads, then everything should work fine. Each client thread has a corresponding servlet thread. But, if I drop the number of maxthreads to 10. Then only 10 clients can get serviced at a time. This seems to work out fine. In the first 5 seconds, the first 10 clients get serviced... then the next 10, and then the next 10. All in about 5 second intervals.

This seems to be as expected, EXCEPT for the fact that I have acceptCount set at 0. Which means that after the frist 10 servlet threads start working, the other 20 should get a rejection from the server (b/c we have used up all the threads and there are no accpetThreads).

But this is not what happens. Instead it seems to buffer the other requests and service the rest of the threads in due time. But the documentation would lead me to think that the clients should have got a connection refused. Any idea what is going on?

-Adam



 
Saloon Keeper
Posts: 27807
196
Android Eclipse IDE Tomcat Server Redhat Java Linux
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Are you sure that "0" doesn't actually mean "unlimited"? Such things have been known to happen.
 
adam spline
Greenhorn
Posts: 18
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Well, I tried it with both 0 and 1 for the acceptCount.

I get the feeling that acceptCount does not work. And there seems to be some other posts that seem to say the same thing. So, i am not quite sure why it is buffering my requests when it should send back a connection refused. Of course, buffering requests is not such a bad thing, I just am trying to explore how the app would work under high stress.

If anyone has an idea.. please pass it on.

Thanks,

-Adam
 
Tim Holloway
Saloon Keeper
Posts: 27807
196
Android Eclipse IDE Tomcat Server Redhat Java Linux
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
I was digging around in that area this last weekend and ran across those parameters, which reminded me of your problem.

If I read the docs correctly (and I was getting pretty frustrated myself), there are at least 2 different connectors, depending on which version of Tomcat you're working with. Tomcat doesn't validate server.xml against a DTD or schema, so if you code a non-supported attribute on an element, it will be ignored, not reported as an error. So it's possible you're using a connector that doesn't support that option.
 
With a little knowledge, a cast iron skillet is non-stick and lasts a lifetime.
reply
    Bookmark Topic Watch Topic
  • New Topic