Tomcat / handling connections when use NIO mode

Question

0.00/5 (No votes)

See more:

Can you please tell me this:

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 thread from pool can switch between 2 or more connections because of 300 > 200 ?

What I have tried:

I tried to find something on the internet.

Posted 27-May-20 8:57am

Member 13702159

Updated 30-May-20 0:38am

Add a Solution

2 solutions

Add a Solution

Add your solution here

Treat my content as plain text, not as HTML

Preview 0

…

Existing Members

Sign in to your account

...or Join us

Download, Vote, Comment, Publish.

Your Email
Password
Forgot your password?

Your Email
This email is in use. Do you need your password?
Optional Password

I have read and agree to the Terms of Service and Privacy Policy
Please subscribe me to the CodeProject newsletters

When answering a question please:

Read the question carefully.
Understand that English isn't everyone's first language so be lenient of bad spelling and grammar.
If a question is poorly phrased then either ask for clarification, ignore it, or edit the question and fix the problem. Insults are not welcome.
Don't tell someone to read the manual. Chances are they have and don't get it. Provide an answer or move on to the next question.

Let's work to help developers, not make them feel stupid.

This content, along with any associated source code and files, is licensed under The Code Project Open License (CPOL)

Greg Utas · Answer 1 · 2020-05-28T11:49:00

I don't know anything about Tomcat, so I will go by your description and the answer that you received to your original question[^].

I don't know what all these threads are for, but I can guess. More than one thread per listener port should not be necessary. One thread can listen for new connections, accept them up to some limit, poll all of the resulting sockets for new packets, recv the packets from those sockets, and with the help of an application callback, assemble them into properly framed messages that are finally queued as work items for application worker threads.

I can think of two reasons why there would be more than one thread per TCP service. First, the thread that does what I just described might not get enough CPU time when it contends with lots of other threads. So the game that gets played is to create more threads to get more CPU time. This is one of the joys of preemptive and priority scheduling, and I've written articles about why it is stupid. But it's what most systems do, so it wouldn't come as a surprise.

Second, application work may run directly off these threads. That is, the system doesn't have a queueing layer between the I/O layer and the application layer. The application doesn't provide its own threads, but is instead invoked by the threads that also service the sockets. This is usually a poor design, but it would also explain the existence of all these threads, especially if applications often perform blocking operations (e.g., disk I/O or reading/writing a database).

This may give you some idea as to what could be going on. If the I/O is non-blocking, 200 threads could well be able to handle 300 clients if the system works as described in the previous paragraph, provided that the application doesn't block the threads so often that none of them are available to handle incoming work.

Greg Utas · Answer 2 · 2020-05-30T00:39:00

The things I described above typically use blocking I/O. But if it's truly non-blocking, here's what could be going on instead.

A global variable keeps track of the last socket that was serviced so that the threads can round-robin through the sockets. When a thread runs, it goes to the next socket and reads it. If the socket has nothing, it goes to the next one, and so on until it finds something. It then invokes the application, telling it which socket (=client) it is serving. The application frames the messages and, when it has a complete message, does the work associated with the message. The next thread to run continues with the next socket, and so on.

This still leaves the question of the listener socket, which needs to be serviced more frequently. There might be a global counter that is initialized to some value. Each thread decrements it, and when it reaches zero, the thread services the listener socket instead of the next client socket.

The result of this will be similar to what I described before. How often the application blocks determines how many threads are needed to handle the clients. If the application never blocks, one thread is enough. The more often the application blocks, and the longer it takes the blocking operations to finish, the more threads will be required. Queueing theory or a simulation would give you a better idea as to how many are actually needed.

Tomcat / handling connections when use NIO mode

2 solutions

Solution 1

Solution 2

Add your solution here

Preview 0