[ https://issues.apache.org/jira/browse/JAMES-3403?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17207901#comment-17207901 ]
Matthieu Baechler commented on JAMES-3403: ------------------------------------------ Well, it's exchanging a correctness fix for a performance fix. You didn't answer my question: does 40000 lookups in this TreeSet really several seconds long? And how about grab 40000 locks on the array? Can you share figures about that please? > IMAP Fetch: UidMSNConverter :: get MSN is slow > ---------------------------------------------- > > Key: JAMES-3403 > URL: https://issues.apache.org/jira/browse/JAMES-3403 > Project: James Server > Issue Type: Bug > Components: IMAPServer > Affects Versions: master > Reporter: Benoit Tellier > Priority: Major > Fix For: master, 3.6.0 > > > # 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. > # 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. > # Short term reaction > Revert uneeded changes added in UidMsnConverter as part of work on JAMES-3177. -- This message was sent by Atlassian Jira (v8.3.4#803005) --------------------------------------------------------------------- To unsubscribe, e-mail: server-dev-unsubscr...@james.apache.org For additional commands, e-mail: server-dev-h...@james.apache.org