[JAMES-3123] Manage properly Cassandra queries concurrency

• Type: Improvement
• Status: Open
• Priority: Major
• Resolution: Unresolved
• Component/s: cassandra
• Assignee: Unassigned
• Reporter: Matthieu Baechler
• Created: 23/Mar/20 10:34
• Updated: 23/Mar/20 10:34

Description

We have several parameters regarding Cassandra usage in James:

• cassandra driver queue size
• cassandra driver threadpool size
• reactor concurrency tuning

We frequently fine tune these parameters based on metrics feedback: for example https://github.com/linagora/james-project/pull/3218 tries to limit the impact of counters computation on the user queries

However, this "try, measure, fix" strategy could be handle by engineering a better execution framework.

I suggest this one:

• use two specific reactor workqueues for running cassandra queries, one for interactive queries and another one for background queries

• ensure we don't schedule more queries than the Cassandra queue size can handle by using back-pressure

• send queries to the right workqueue depending on the expected execution characteristics