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