[JAMES-3403] IMAP Fetch: UidMSNConverter :: get MSN is slow

• Type: Bug
• Status: Closed
• Priority: Major
• Resolution: Fixed
• Affects Version/s: master
• Fix Version/s: master, 3.6.0
• Component/s: IMAPServer
• Assignee: Unassigned
• Reporter: Benoit Tellier
• Created: 05/Oct/20 07:45
• Updated: 06/Oct/20 01:22
• Resolved: 06/Oct/20 01:22

Description

1. What?

Following openpaas-1.7.15-rc2 deployment, and the use of VAVR immutable datastructures in UidMsnConverter, I notice some offending slow FETCH requests.

A closer look shows Cassandra is not to blame here

Flame graphs correlate the analysis

On our prod set up 40k messages are enough to trigger endless FETCHs.

1. Why ?

Fetch is calling getMSN(uid) one by one.

Previous code was "getMSN optimized" as it uses an array as the underlying data structure. O(1) upon reads * n messages.

The later code uses a red-black tree as an underlying data structure. I'm usure about the complexity here (because I am not a VAVR expert) but it is at least O(log n) * n messages.

1. Short term reaction

Revert uneeded changes added in UidMsnConverter as part of work on JAMES-3177.