tomcat - thread pool

[Bronislav Bronek]

Could you please explain me this sentence?

"With a monitoring tool, you can calculate the number of idle threads by comparing the current thread count to the number of busy threads."

What is the current thread?  
What is the busy thread?

[Stephan van Hulst]

The sentence doesn't refer to a current thread. It refers to a current number of threads. It also doesn't refer to any particular busy thread, just the number of all busy threads.

If you subtract the number of busy threads from the total number of threads, you get the number of idle threads.

[Bronislav Bronek]

the total number of threads = 200  by default in tomcat ?

200  -  the number of busy threads =  the number of idle threads.


Tell me please the difference between   the current thread and   the busy thread?

[Paul Clapham]

A "busy" thread is one which is doing something. An "idle" thread is one which is doing nothing. Naturally all threads are either busy or idle, but not both.

The term "current thread" doesn't mean anything. The word "current" -- at least this version of the word -- means "at the present time". So I suppose the "current thread" might mean the one you're looking at now, or something like that. But you just made that up by picking words out of the quote you posted.

[Bronislav Bronek]

So, thread in tomcat can be either busy or idle.

default value of threads pool is 200

is this relation correct ?

( 200 - total number of idle threads) = total number of busy threads

[Tim Moores]

I don't know about 200 - threads are configured in conf/server.xml, you can check what your installation uses. Either an Executor like "tomcatThreadPool", or via a maxThreads setting for each Connector.

One monitoring tool you can use to investigate is VisualVM and its Threads tab. Its MBeans plugin allows you to look at both Tomcat's settings and the underlying JVM settings. The relevant JMX objects are java.lang:type=Threading and Catalina:name=ajp-nio-127.0.0.1-9589,type=ThreadPool (or something like it).

[Bronislav Bronek]

here is

maxThreads  = (int) The max number of active threads in this pool, default is 200

http://tomcat.apache.org/tomcat-7.0-doc/config/executor.html

[Tim Moores]

That goes goes back to what I said about the server.xml file - that's what counts. By default, no Executor (which is what that page talks about) is active. And the maxThreads setting of the Connector is by default set to 150; see https://github.com/apache/tomcat/blob/master/conf/server.xml

By the way, I hope you're not really using Tomcat 7. Unless there's a pressing reason for it, upgrade to 8.5 or 9, which implement newer versions of the Servlet and JSP APIs. See https://tomcat.apache.org/whichversion.html to help you decide.

[Bronislav Bronek]

Tell me please this -

I have a webSocket server which is runnnig on Tomcat.
Tomcat works in NIO – non-blocking I/O (many more connections than threads) mode.

maxConnections = 1000
maxThreads = 200

Assuming 300 connections for example , all 300 users can be serve by Tomcat ??

I mean, one thred from pool can switch between 2 connections because of 300 > 200 ?

[Tim Holloway]

Tomcat has 2 thread pools. One pool services incoming connection requests, one runs the application services (servlets and JSPs).

Tomcat adheres to standard TCP/IP server architecture. It has a Listener for the incoming HTTP port (also for its other ports such as HTTPS, command, and AJP).

When a client sends a request to Tomcat, the Listener dispatches one of the connection threads to handle it. The connection thread is responsible for accepting the request and distilling it into Tomcat internal objects (including the HTTPRequest object). If more connection requests come in than there are connection threads in the pool, the connection request "bounces" and the client is informed that a connection cannot be made. An incoming request may also bounce if the queue of requests received and awaiting processing is full.

Once a request has been distilled and queued internally, the service dispatcher attempts to obtain a Thread for the request service pool. It then passes the request to that thread and initiates the chain of processing calls that ultimately lead into the actual application code itself. Once the application code has finished with the request and returned, the Thread is returned to the request processing pool where it can be handed over to the next waiting request or, if no requests are waiting, the Thread will be placed in the pool's idle queue.

[Bronislav Bronek]

I have maxThreadPool = 200

When I create 250 users and run in the same time I see that all 250 are handled.

Could you explain me how it is posiible. You wrote that where there is not more threads in pool -  the connection request "bounces"

[Tim Holloway]

Almost all of the time you spend on a webapp is what in time-sharing days was known as "think" time. In other words, the computer is so much faster than you are that it can do its work and go back to waiting and spend nearly 100% of wall-clock time waiting on the user to think what they'll do next.

HTTP connections are not persistent. You could have 10,000 concurrent users, but odds are good that maybe only 200 of them are actively using the server simultaneously. The rest are in "think" time, and since, as I said, HTTP is not persistent, that means that they are not only not running threads, they're not even connected to the server. Then a user clicks a button and a request needs a thread. And sends a response which requires resources so there's maybe a dozen or more requests for images, CSS, javascript and other page decorations, but those are all very small requests (we hope!) and so they get handled quickly. To truly max out a thread pool, you'd generally need a lot of bots making frequent requests. So for example, web services. Or a DDOS attack.

[Bronislav Bronek]

What about the situation when I have 250 web socket connections ?

I see that 250 connections are opened

[Tim Holloway]

Connections are not the same thing as threads. A single thread may open 1000 connections, if the OS network stack can spare them.

However, please note that all 1000 of them MUST be closed before the thread is returned to the pool!