How Thread Per Connection Uses Thread Pool
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?
Answer
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.
Related Questions
- → How to update data attribute on Ajax complete
- → October CMS - Radio Button Ajax Click Twice in a Row Causes Content to disappear
- → Octobercms Component Unique id (Twig & Javascript)
- → Passing a JS var from AJAX response to Twig
- → Laravel {!! Form::open() !!} doesn't work within AngularJS
- → DropzoneJS & Laravel - Output form validation errors
- → Import statement and Babel
- → Uncaught TypeError: Cannot read property '__SECRET_DOM_DO_NOT_USE_OR_YOU_WILL_BE_FIRED' of undefined
- → React-router: Passing props to children
- → ListView.DataSource looping data for React Native
- → Can't test submit handler in React component
- → React + Flux - How to avoid global variable
- → Webpack, React & Babel, not rendering DOM