[
https://issues.apache.org/jira/browse/JAMES-3403?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17207879#comment-17207879
]
Matthieu Baechler commented on JAMES-3403:
------------------------------------------
Do you mean that 40k lookups in this vavr datastructure takes several seconds?
> 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
