File APIs for Java Developers
Manipulate DOC, XLS, PPT, PDF and many others from your application.
The moose likes Tomcat and the fly likes maximum number of threads for one servlet Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login
JavaRanch » Java Forums » Products » Tomcat
Bookmark "maximum number of threads for one servlet" Watch "maximum number of threads for one servlet" New topic

maximum number of threads for one servlet

Jomy George
Ranch Hand

Joined: Jan 13, 2011
Posts: 68
Hi Friends,

Is there a way in tomcat to configure maximum number of threads created for a single servlet?

Thanks in advance
Tim Holloway
Saloon Keeper

Joined: Jun 25, 2001
Posts: 17410

Yes. The number is 1. You can "set" it to 1 or you can "set" it to 1.

Servlets are forbidden from spawning threads by the JEE spec.

The reason for this is the answer to the other way that your question could have been read, which would more accurately be "can I limit how many thread instances of a servlet can run at once?"

The answer to that question in 0. You can "set" it to 0.

Servlets are not tasks, processes, threads or whatever you wish to call them, They don't "run". Servlets are code resources that are invoked by Tomcat's request/response handler threads, which are kept in a common thread pool and assigned when incoming Http requests come in. One request gets one thread. The URL mapper then picks a servlet (which may have been a compiled JSP) from the webapp's URL/servlet map and tells the assigned thread to invoke the servlet's service() method.

Because the request-handler thread isn't itself user application code (although it invokes user-application code) and because the request-handler threads are intended to be identical resources pulled from a pool, used as briefly as possible, and then returned to a pool, the threads must not spawn child threads, since the children would upset the symmetry of the thread pool if still running or, conversely, if you waited until all children were done, you'd be bottle-necking the primary request/response handling mechanism. Likewise if you spawned no children but placed the servlet itself into an extended blocked state.

Ideally, all webapp code should be quick in-and-out functions and when that approach is used, the thread-pool approach works very efficiently. Sometimes in real life, we need things that are best done on a slower scale. For stuff like that, you can spawn out-of-band threads in code initiated from a ServletContextListener at webapp startup time. Servlets can then offload long-running stuff to these "engine threads". Providing that they don't then block waiting for the engine threads.

An IDE is no substitute for an Intelligent Developer.
I agree. Here's the link:
subject: maximum number of threads for one servlet
It's not a secret anymore!