Benoit Tellier created JAMES-3773:
-------------------------------------
Summary: Reactor elastic -> boundedElastic switch
Key: JAMES-3773
URL: https://issues.apache.org/jira/browse/JAMES-3773
Project: James Server
Issue Type: Improvement
Components: James Core
Affects Versions: 3.7.0
Reporter: Benoit Tellier
Fix For: 3.8.0
A scheduler is the abstraction Reactor, our reactive library runs code on.
Ideally we would only run non-blocking code on a parallel scheduler. In
practice we also run blocking code on an elastic scheduler. Elastic schedulers
are unbounded so we can end up with a very large number of threads thus
defeating the benefits of reactive code.
For this reason, project reactor deprecates elastic in favor of bounded elastic.
This switch was attempted before but resulted in dead locks.
Such deadlocks can be avoided by:
- Avoiding wrapping .blocks calls in an elastic thread. This means essentially
improving the quality of our reactive pipelines and not blocking them in the
middle. - Avoid calls to subscibeOn before blocking. Instead use the blocked
threads (that is anyway blocked) for the ongoing computation.
- In last result use a SEDA like approach:
- Introduce a new instance of boundedElastic dedicated to wrap our calls to
.block where we can't avoid it. - Use core boundedElastic only when no
reactor .block call is involved to prevent starvation
Alternatives would be to increase to an absurd amount the size of
boundedElastic essentially mimicking the behavior of elastic.
We have 161 calls to .elastic().
Acceptance criteria: no performance degradation. Recent performance
improvements were furthermore delivered in recent reactor releases.
This would eventually be needed to upgrade to reactor 3.5.0.
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscr...@james.apache.org
For additional commands, e-mail: server-dev-h...@james.apache.org
