Benoit Tellier created JAMES-3737:
-------------------------------------
Summary: Reactive IMAP implementation
Key: JAMES-3737
URL: https://issues.apache.org/jira/browse/JAMES-3737
Project: James Server
Issue Type: Improvement
Components: IMAPServer
Reporter: Benoit Tellier
Netty is an asynchronous IO framework yet we do not leverage its full potential
.
Combined with our reactive mailbox API we could leverage non blocking code for
the IMAP protocol (for instance).
Going reactive in IMAP have the following benefits:
- Latency reduction
- Threading model improvements
- Backpressure
I did succeed to come up with a Proof Of Concept wich achieve ~ 15% mean
latency reduction and ~40% p99 latency reduction. By just porting to reactive
the most used IMAP processors.
Also I did propose a model for a progressive migration for existing processors:
reactive and blocking processors could co-exist. The way it works is that :
- Blocking processors are just wrapped into a mono
- processing operations are subscribed on the IMAP worker thread (on which
blocking is OK)
In the context of a blocking processor, the behaviour is the same as before:
blocking on the IMAP worker threads.
In the context of reactive processor, we just subscribe the operation in the
IMAP worker thread.
Please note that we could then imagine getting fully rid of the IMAP worker
thread, instead realying on (bounded) elastic scheduler for IMAP request
processing where needed. THis would enable getting rid of a context switch and
trigger the processing operations directly from the epoll event loop - this is
for instance what the AWS driver does. THis would also require, to be
effective, similar changes to be performed at the level of the IMAP request
parsing, that *might* copy data to a file, which is blocking (large IMAP
append).
Further work is needed to determine if we can get rid of the IMAP worker
threads.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscr...@james.apache.org
For additional commands, e-mail: server-dev-h...@james.apache.org
