Benoit Tellier created JAMES-3816:
-------------------------------------
Summary: Limit IMAP concurrent requests
Key: JAMES-3816
URL: https://issues.apache.org/jira/browse/JAMES-3816
Project: James Server
Issue Type: Improvement
Components: IMAPServer
Reporter: Benoit Tellier
h2. Context
In James 3.7.0 IMAP concurrency model was based on the thread pool model: a
pool of (eg) 20
threads conducts 20 blocking tasks simultaneously.
This lead to resource usage inefficiency: to handle 1000 requests at a given
time, we need 1000 threads
and OS threads are expensive.
However, this also put some concurrency control in place that protects the IMAP
server of bursts as no
more requests than the count of threads could be processed.
In JAMES-3737 we migrated to a reactive model. IMAP stack had been
re-implemented to be asynchronous. A
few threads (typically matching the count of CPU) would carry out an
arbitrarily large amount of IMAP
requests simultaneously. This is efficient resource wise, but there is no more
some concurrency control
mechanisms in place.
On a production environment, I notice some bursts of a few seconds where an
Apple mail client fires thousands
of IMAP requests, which exhaust server resources: S3 connections, Cassandra
queries times out at consistency serial.
h2. Solution
Put back concurrency control on top of the IMAP reactive stack.
We can take inspiration from the Cassandra driver throttlers to do so:
* Defines a maximum number of concurrent requests
* Have a queue for request delayed because maximum execution level is exceeded
* Once executed, execution of other requests are triggered
* If exceeding the queue size requests are rejected
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscr...@james.apache.org
For additional commands, e-mail: server-dev-h...@james.apache.org
