Multithreading with Jersey

Question

Here are two links which seem to be contradicting each other. I'd sooner trust the docs:

Link 1

Request processing on the server works by default in a synchronous processing mode

Link 2

It already is multithreaded.

My question:

Which is correct. Can it be both synchronous and multithreaded?

Why do the docs say the following?:

in cases where a resource method execution is known to take a long time to compute the result, server-side asynchronous processing model should be used

If the docs are correct, why is the default action synchronous? All requests are asynchronous on client-side javascript by default for user experience, it would make sense then that the default action for server-side should also be asynchronous too.

If the client does not need to serve requests in a specific order, then who cares how "EXPENSIVE" the operation is. Shouldn't all operations simply be asynchronous?

Answer 1

Request processing on the server works by default in a synchronous processing mode

Each request is processed on a separate thread. The request is considered synchronous because that request holds up the thread until the request is finished processing.

It already is multithreaded.

Yes, the server (container) is multi-threaded. For each request that comes in, a thread is taken from the thread pool, and the request is tied to the particular request.

in cases where a resource method execution is known to take a long time to compute the result, server-side asynchronous processing model should be used

Yes, so that we don't hold up the container thread. There are only so many threads in the container thread pool to handle requests. If we are holding them all up with long processing requests, then the container may run out of threads, blocking other requests from coming in. In asynchronous processing, Jersey hands the thread back to the container, and handle the request processing itself in its own thread pool, until the process is complete, then send the response up to the container, where it can send it back to the client.

If the client does not need to serve requests in a specific order, then who cares how "EXPENSIVE" the operation is.

Not really sure what the client has to do with anything here. Or at least in the context of how you're asking the question. Sorry.

Shouldn't all operations simply be asynchronous?

Not necessarily, if all the requests are quick. Though you could make an argument for it, but that would require performance testing, and numbers you can put up against each other and make a decision from there. Every system is different.