I want to run a java application and get all http requests in the main thread (or another), then create a thread for each request, and then return the response back to the client. Tomcat -as i know- handles each request in a new proccess, and i cannot do it with thread. Is there any solution fast enough for that? There is a lot of solutions for embedding a web server inside a java app here. But which one can do multithread and is the most secure and fast?
Tomcat -as i know- handles each request in a new proccess, and i cannot do it with thread.
Incorrect. Tomcat works exactly as you want: It creates one thread for each incoming HTTP call; this thread begins by disassembling the incoming request (e.g. pick the path out of GET /foo/bar/this/is/the/path HTTP/1.1, then read through the headers, and so on), then using its routing system to figure out where the code lives that is supposed to handle this incoming request, and then calls that handler code. That handler code will, as part of its lifecycle, send data back to the client. Once it is done, the thread 'ends'.
A few details about all this:
If you are using servlets as the framework to write your code in, you get the worst of both worlds: The servlet runner may or may not create an instance of your handler class. Generally it does not, so, you can't store any state in fields. servlets are pretty crappy design, there are plenty of frameworks out there such as Jersey, apache spark that uses object lifecycles more usefully than servlets do.
A thread 'ends' does not mean the thread is abolished. Most frameworks 'recycle' them. They have a set number of handler threads and each thread actually runs in a loop: It picks a 'job' (an incoming HTTP request) out of the queue on a first come first served basis, disassembles that request, uses the routing table to find the endpoint code that handles it, calls that, and once that endpoint is done (via exception or normally, doesn't matter), the thread moves on to the next item in the job queue. These frameworks limit the 'thread pool' for handling jobs to something like 50 because that's actually more performant (at some point it's faster to fully serve 50 customers simultaneously and let the next 50 wait in line, then trying to serve 100 simultaneously; it's no faster to get through 100 requests, and the '50 at once' model does mean at least 50 of them have their request actually completed faster). They all have the property that you can configure how large this pool is, and you can set it to 5000 or something similarly high if you really want that. I strongly suggest you do some performance testing, and if you want high numbers, make sure the box has loads of RAM.
All frameworks do what you want - none spawn processes per connection. Some frameworks go even further and don't actually use 1 thread per incoming connection, the so-called async frameworks. JDK22 ships with virtual threads which is why there's a lot of hype about these frameworks. Async is mostly useless (it promises less overhead per connection, but, modern systems can fairly easily handle thousands at a time; threads is rarely the bottleneck. But, "web scale!" is such an overhyped mass delusion that there's a lot of traffic out there about how threads are evil for some reason) - but in the rare case where you need it, Virtual Threads makes writing code in that model a lot simpler.
I'm guessing you're asking the question because you want to handle lots of connections at the same time; these async frameworks purport to be able to handle even more, so I don't think that's an issue for you. Hence, we're back to: Literally every single web framework in existence in the java ecosystem is as fast, or faster, as you want.