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.
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.
Joined: Sep 29, 2010
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?
Are you sure that "0" doesn't actually mean "unlimited"? Such things have been known to happen.
Customer surveys are for companies who didn't pay proper attention to begin with.
Joined: Sep 29, 2010
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.
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.