[ 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: server-dev-unsubscr...@james.apache.org For additional commands, e-mail: server-dev-h...@james.apache.org