[jira] [Created] (JAMES-3773) Reactor elastic -> boundedElastic switch

["Benoit Tellier (Jira)" <se...@james.apache.org>]

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-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org