[
https://issues.apache.org/jira/browse/JAMES-3204?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17133339#comment-17133339
]
Raphael Ouazana commented on JAMES-3204:
----------------------------------------
[https://github.com/linagora/james-project/pull/3428] should have taken care of
it, but we still need to run some load testing to check the global behavior
> CassandraMessageMapper badly applies LIMIT
> ------------------------------------------
>
> Key: JAMES-3204
> URL: https://issues.apache.org/jira/browse/JAMES-3204
> Project: James Server
> Issue Type: Improvement
> Components: cassandra, mailbox
> Affects Versions: 3.5.0
> Reporter: Benoit Tellier
> Priority: Major
> Fix For: 3.6.0
>
>
> We noticed some `BusyPool` exceptions filling up the driver queue upon IMAP
> query (FETCH flags for all the messages in the mailbox).
> The MessageManager do batch those reads (by default by 200 for metadata).,
> wich then call the MessageMapper with this limit.
> Some unit tests performed at the Cassandra mailbox level proved the soft
> filtering did badly applies, and that we were performing uneeded extra reads
> for the full batch read from the database.
> One good mitigation strategy is to push the limit to the Cassandra query, and
> ensures filtering happens before the extra reads are performed.
> https://projectreactor.io/docs/core/release/api/reactor/core/publisher/Flux.html#take-long-
> documents that it just don't propagate downstream request once a given
> amount is reached however it do not ensure any form of backpressure. We might
> want to further audit our code, looking for similar take mis-usages.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
