EmitterProcessor: cyclical LockSupport.parkNanos(10) gives CPU load 100%

[mayras]

EmitterProcessor has next code inside onNext(), line 266:

		while (!q.offer(t)) {
			LockSupport.parkNanos(10);
		}
		drain();

In some cases, flow statement "while" executes forever and it gives very high CPU usage, almost 100%, because LockSupport.parkNanos(10) executes without stop until some subscriber will be attached, all incoming threads stay inside "while" who invoked onNext, because queue is full and there is no drain until new subscriber is attached. If you look inside method "drain", you will see that queue.poll is executed when at least one subscriber is attached only.

Possible Solution

Not so sure about solution, but it can be partial draining if queue is full

Your Environment

• Reactor version(s) used: 3.3.2.RELEASE
• JVM version (javar -version): 11.0.6
• OS and version (eg uname -a): win10pro 1909

[simonbasle]

@smaldini I need your insight on that one, but IIRC the intention is that filling up the queue is only ever supposed to be a temporary situation. You're not supposed to use an EmitterProcessor to feed a ton of data without connecting at least one Subscriber in a timely fashion.

[osi]

I hit a related problem with this construct; In trying to write a test for the EmitterProcessor queue being full, I realized that it is ignoring thread interruption while in this hot loop (which means that I can't use JUnit's @Timeout to write for prevention)

[smaldini]

@simonbasle you are correct. We should be explicit on this behavior when building the processor maybe. Or provide specific API for "whenSubscriber(Consumer xxxx)" and remove this behavior altogether in a future version. This is also a problem of over producing.

[mayras]

Guys, can we fix this issue? It's really painful and happens everywhere, CPU 100%, I don't know how people use Reactor in production, it happens even with simple reactor-logback:

[simonbasle]

@smaldini will you be able to take that one ?