How exactly does Tomcat's Threadpool work [closed]

Question

So here's my understanding.

The Apache Tomcat's threadpool (is it called the connector Threadpool? ) has a number of threads ( 200 by default ). Now this means that at a particular time, 200 people can communicate with my web application.

Now, taking a scenario when a particular connects with my application. I get a request, and the tomcat client on the server checks if there is any thread available to cater to the request or not. If it is then good, else we give back some error code. Now in case of success, will that one thread, that I have assigned to that request, be associated with that particular client till the time his request is not handled?

Basically, as a user if I go to, www.myApp.com, I get one thread from the thread pool that fetches all the info from the server and gives me back the final html. After that the thread is free and goes back to pool. Now if I click on something else then again go to the threadpool and get assigned a thread if available and it goes on a on. Is this how it works?

Question 2

Let's say, I have a Java Application on my server side. So when I hit a url, it takes me to some java code. Now is it that, the thread that I got from Tomcat Threadpool, that thread will execute my code?

If that is so, what happens if I make new threads in my java code, will those threads be taken from the Tomcat's threadpool or will those be from the Java's threadpool created? Also, what happens to the execution of the Tomcat's thread in that case?

Thanks.

Kindly provide some Tomcat official references/resources where I can read about such things if you know about any. Cheers.

Answer 1

Now this means that at a particular time, 200 people can communicate with my web application.

Not exactly. It means that your server can process 200 requests simultaneously¹. There can be a number of other requests in the queue waiting for a thread to become available.

Now in case of success, will that one thread, that I have assigned to that request, be associated with that particular client till the time his request is not handled?

Yes ... unless you are using the asynchronous request handling features added in a recent version of the Servlet spec. (In that case, it may be possible to process more than 200 requests "simultaneously" with 200 threads. But that would entail one request surrendering control to another request while it waits for something to happen. Read this for introduction.)

Is this how it works?

More or less ...

^{1 - To be pedantic, you would (probably) need 200+ cores for the processing of 200 requests to happen at the same instant in time. So, I'm using "simultaneously" from the perspective of the end-users, who have no visibility of what is actually happening inside the server "black box". But having said that, it is not impossible for one physical thread / core to be performing work for multiple requests at the same instant in time. The most obvious case is where there are lots of identical requests that are handled together.}

---

Let's say, I have a Java Application on my server side. So when I hit a url, it takes me to some java code. Now is it that, the thread that I got from Tomcat Threadpool, that thread will execute my code?

This doesn't make sense. If you have a Java application on the server side, then you need to explain how you go from an HTTP request ("hitting[sic] a url") to running the Java application. Only then can we tell you whether or not a threadpool thread is involved.

If that is so, what happens if I make new threads in my java code, will those threads be taken from the Tomcat's threadpool or will those be from the Java's threadpool created? Also, what happens to the execution of the Tomcat's thread in that case?

Once again, it depends how your Java application is being run. For instance, if your webapp is using Runtime.exec("java ... classname") to run the application on the server-side, then it is in a separate JVM to your Tomcat, and none of the application threads will be in the Tomcat thread pool.

It has also been pointed out that there is no "Java threadpool" per se. If your Java application chooses to, it can create and use a thread pool. But if it doesn't, then Java threads are not pooled. They are largely disposed of when they terminate, and any remaining data structures are reclaimed when the Thread object is garbage collected.