4

I've been reading about Java Fibers as small unit of work which would mapped to Threads. In case of a blocking call a different Fiber would be mapped to the same Thread. Since Threads in Java are kernel level threads, this would prevent Threads from getting exhausted.

I've been using Spring Web-Flux, so just wanted to understand What all happens internally when Netty server receives 100 request/sec each of which include reactive databases access, How are these requests mapped to 40 threads which Netty server spawns by default?

How is a flux different from a Fiber? How does flux guarantee asynchronous behaviour with limited number of threads?

Apurv
  • 315
  • 5
  • 14

1 Answers1

6

What all happens internally when Netty server receives 100 request/sec each of which include reactive databases access, How are these requests mapped to 40 threads which Netty server spawns by default?

In brief, it takes those requests and assigns them "round robin" style to each available underlying thread (as those threads become available.) The same thing happens with all other reactive calls too, of course with the caveat that depending on the configuration, they may be running on other schedulers and so other underlying thread pools with different numbers of threads.

How is a flux different from a Fiber?

That's a very big topic, but the "high level" overview is that flux (by which I assume you mean "reactive" Java rather than a Flux itself) is an asynchronous model where no thread is allowed to block, and fibers are "green" threads, designed to be used synchronously, that make use of preemptive scheduling (amongst other techniques) to map to far fewer underlying kernel level threads.

In practice, that means that you can use pretty much the same threading model & code techniques you do today with fibers, but reactive programming will require you to adopt new paradigms.

How does flux guarantee asynchronous behaviour with limited number of threads?

Quite simply, because it's architected to be asynchronous. The question here seems like it's based on a false premise - asynchronous behaviour isn't guaranteed or not guaranteed by the number of threads available, but by your model (it can't "spill over" into synchronous behaviour if it's overwhelmed by requests.)

Michael Berry
  • 70,193
  • 21
  • 157
  • 216
  • Flux have their own Threadpool right? and they have their own scheduling, Does a Flux also use Preemptive Scheduling? Fibers use non-blocking IO do Flux also use the same? – Apurv Mar 18 '20 at 07:07
  • I think you're confusing terms here - a flux uses whatever scheduler (and therefore whatever underlying executor) you assign to it. Those schedulers *usually* wouldn't contain threads that used preemptive scheduling, - that wouldn't make much sense, since you shouldn't be blocking on those threads anyway (they would usually be kernel level threads.) Reactive programming does use non-blocking IO (it uses non-blocking everything, which is the very point of it) - but Fibers are just another type of thread, so whether you use them to execute blocking or non-blocking IO is entirely up to you. – Michael Berry Mar 18 '20 at 08:39