• 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

maximum number of threads for one servlet

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

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

Thanks in advance
Jomy
 
Saloon Keeper
Posts: 27763
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
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.
 
reply
    Bookmark Topic Watch Topic
  • New Topic