Details
-
Improvement
-
Status: Closed
-
Major
-
Resolution: Fixed
-
None
-
None
-
None
Description
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.
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
