[jira] [Commented] (JAMES-3737) Reactive IMAP implementation

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

    [ https://issues.apache.org/jira/browse/JAMES-3737?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17513309#comment-17513309 ] 

Benoit Tellier commented on JAMES-3737:
---------------------------------------

ByteToMessageDecoder , which ImapRequestFrameDecoder is based on, is synchronous..

Thus `if we can get rid of the IMAP worker threads` is not feasible.

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