[GitHub] [james-project] Arsnael commented on a diff in pull request #1196: [BOYSCOUT] Write some missing ADRs regarding recent work

[GitBox <gi...@apache.org>]

Arsnael commented on code in PR #1196:
URL: https://github.com/apache/james-project/pull/1196#discussion_r973854839


##########
src/adr/0060-adopt-bounded-elastic.md:
##########
@@ -0,0 +1,60 @@
+# 60. Adopt bounded elastic
+
+Date: 2022-09-13
+
+## Status
+
+Accepted (lazy consensus).
+
+Implemented. 
+
+## Context
+
+See description of blocking vs reactive programming odel described in [ADR-57](0057-reactive-imap.md).
+
+Sometime Reactive code needs to execute blocking tasks. 
+
+ - This is the case when inter-operating with blocking libraries
+ - James reactive adoption is progressive, some parts of our application
+ are thus not reactive yet, which can result in reactive code calling
+ blocking code calling reactive code.
+ 
+Historically James used the elastic scheduler for scheduling such blocking calls. This scheduler
+starts a thread for each task submitted (and attempt to reuse threads when possible) and results
+in high thread count.
+
+That is why project reactor deprecated the elastic scheduler in favor of bounded-elastic (similar to
+a thread pool).
+
+## Decision
+
+Migrate from elastic scheduler to bounded-elastic scheduler.
+
+## Consequences
+
+We expect a reduction in used threads under load from such a change.
+
+Also, getting rid of elastic scheduler might be a requirement to upgrade to reactor 3.5 upward.
+
+Associated risk:
+ - In some places, James protocol code is reactive, calls blocking intermediates API, to 
+ end up calling reactive data access code. This results in nested blocking calls. Nested blocking
+ calls, when using the same scheduler with a bounded thread cap, can result in a dead lock.
+
+To prevent such a dead-lock code executed on bounded-elastic should not depend on scheduling nested
+blocking call on bounded-elastic scheduler for its completion. We can thus avoid such a situation by 
+using a scheduler dedicated by nested blocking calls.
+
+## Alternatives
+
+Alternatives to the "blocking call wrapper" scheduler describes above includes a full reactive 

Review Comment:
   ```suggestion
   Alternatives to the "blocking call wrapper" scheduler described above includes a full reactive 
   ```



##########
src/adr/0060-adopt-bounded-elastic.md:
##########
@@ -0,0 +1,60 @@
+# 60. Adopt bounded elastic
+
+Date: 2022-09-13
+
+## Status
+
+Accepted (lazy consensus).
+
+Implemented. 
+
+## Context
+
+See description of blocking vs reactive programming odel described in [ADR-57](0057-reactive-imap.md).
+
+Sometime Reactive code needs to execute blocking tasks. 

Review Comment:
   ```suggestion
   Sometimes reactive code needs to execute blocking tasks. 
   ```



##########
src/adr/0060-adopt-bounded-elastic.md:
##########
@@ -0,0 +1,60 @@
+# 60. Adopt bounded elastic
+
+Date: 2022-09-13
+
+## Status
+
+Accepted (lazy consensus).
+
+Implemented. 
+
+## Context
+
+See description of blocking vs reactive programming odel described in [ADR-57](0057-reactive-imap.md).

Review Comment:
   ```suggestion
   See description of blocking vs reactive programming model described in [ADR-57](0057-reactive-imap.md).
   ```



-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: notifications-unsubscribe@james.apache.org

For queries about this service, please contact Infrastructure at:
users@infra.apache.org


---------------------------------------------------------------------
To unsubscribe, e-mail: notifications-unsubscribe@james.apache.org
For additional commands, e-mail: notifications-help@james.apache.org