Multithreading with Jersey

前端 未结 1 1732
后悔当初
后悔当初 2021-01-13 17:40

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 def

相关标签:
1条回答
  • 2021-01-13 18:13

    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.

    0 讨论(0)
提交回复
热议问题