3

I'm using Spring Boot and embedded Tomcat(8) and in app.prop file we have two options:

server.tomcat.max-connections = 1000
server.tomcat.max-threads= 20

From tomcat docs I have read that first option is the max number of connections that server can handle and second option is the max number of threads in Tomcat's thread pool. After that I understand , connections and requests are not the same words as I tought . After that I read this topic

What is the difference between thread per connection vs thread per request?

The main points from topic are:

Thread per request will create a thread for each HTTP Request the server receives

Thread per connection will reuse the same HTTP Connection from multiple requests

After the words reuse the same HTTP Connection I checked Http keep-alive.

Th concept: after response, server and client are able to keep open connection.

But how is it possible? I mean When I send request to the server one thread from thread pool will receive my request then send me a request , after that according to Http keep-alive my connection is not closed. Where is it stored, what will happen when i send another request, does the same thread will procide my request?

Almas Abdrazak
  • 3,209
  • 5
  • 36
  • 80

2 Answers2

2

So this question was posted by me 3 years ago. The main thing that I didn't understand at that time is how Amount of threads is different from amount of connections. This is really confusing for beginner Java developers because Java provides an abstraction above user level threads and it's not clear what is connection in this context.

So for Unix based systems amount of connections is the total amount of File Descriptors your server can open at the same time. Let's say amount of connections is 100 and amount of threads is 10. It means when User sends request to server, server creates a file descriptor for this request and If all Tomcat's threads are busy then this file descriptor will be processed as soon as one thread will be available. In order to open multiple File descriptors Tomcat (8+) uses NIO connector which is based on Event loop. The main point here is that tomcat has one(this number is configurable) thread that is listening for incoming requests, create associated file descriptors and when server finished a processing, sends this response to client by using file descriptor.

BTW, this is how Nodejs works under the hood, if you are interested I wrote a blog post about it https://strogiyotec.github.io/pages/posts/io.html

Almas Abdrazak
  • 3,209
  • 5
  • 36
  • 80
-1

Where is it stored,

That's an implementation detail - not at all important for developing an application on top of Tomcat. You'd have to look up the source code of Tomcat for this, but I think this is completely unnecessary. It won't teach you anything unless you'd like to go into tomcat development. Just for apps: Ignore it.

what will happen when i send another request,

it will be handled. Period.

does the same thread process my request?

Nope. Or: Randomly yes. Any thread that's currently free to process a request will be used to handle this request.

Your question hints at some expectations that are dangerous: You must not assume anything in request handling other than all of the current state being encapsulated in the request and response object that gets handled into your servlet. No other assumption can be made - in fact, any other assumption (e.g. about threads, servlet's member variables) typically is wrong.

The container (tomcat) does a great job to isolate your application from those low level details. Don't go in there and mess with it. You can make no assumption about any consistency between handling of one request and the next, other than what you find in the request and response objects.

Olaf Kock
  • 46,930
  • 8
  • 59
  • 90
  • If you don't get into the details, how do you tune your application's performance for processing high loads? There are a bunch of parameters that tomcat exposes for this exact reason. And if you don't understand some of the terms / concepts, you wouldn't be able to fine tune anything. Let me know if I'm missing something here. – Rushil Paul Jan 11 '23 at 02:22
  • @RushilPaul Application tuning does not rely on which thread handles which request - that is completely irrelevant. Imagine that the thread that handled your previous request is now busy serving a 100M download through a slow connection - you definitely wouldn't want to wait for it. And that's the aspect that I've referred to in my answer. Yes, performance tuning is a thing, but no, it's not on this level. The connection and the thread serving a request on that connection are totally independent of each other. And that's good. – Olaf Kock Jan 11 '23 at 09:10