Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [jetty-dev] New Scheduling idea for 9.3





On 31 July 2014 09:13, Simone Bordet <sbordet@xxxxxxxxxxx> wrote:

I don't see how ?
Every time we parse a HEADERS we need to call the app.
For each HEADERS we need a dispatch (and it's done before calling the app).
I think we will submit N-1 tasks to the thread pool in all cases (best
or worst).
And then the thread pool can handle those N-1 jobs with M threads
(where M <= N-1), but that is the usual case of thread pools anyway
(we are in the same situation with the current code).

Simone,

consider the case of a busy thread pool and a connection that receives N simple non -blocking requests:
  • Thread X parses request N.
  • Thread X dispatches to thread Y
  • Thread X handles request N
  • Thread X completes request N and parses request N+1
  • Thread X sees that new thread not yet arrived, so does not dispatch again
  • Thread X handles request N+1
  • Thread X completes request N+1 and parses request N+2
  • ...
  • Thread X completes request N+n and see that was the last and returns
  • Thread Y now arrives, finds empty buffer, returns

So in this best possible case, only 2 dispatches are needed.

See the volatile dispatched boolean in the EWYK strategy in https://github.com/eclipse/jetty.project/blob/jetty-http2/jetty-util/src/main/java/org/eclipse/jetty/util/thread/ExecutionStrategy.java

that is protecting from extra dispatches.

Now if the if thread pool is idle, thread Y will turn up quickly and will probably arrive before X has finished handling, so it will do a parse and handle itself.     It is only if Y arrives while X is in the parsing phase will Y be a noop.

cheers




 

Back to the top