Hello folks, I want to raise this concern to the mailing list.
As described in https://issues.apache.org/jira/projects/JAMES/issues/JAMES-3589 One of my customer reported me that a side effect was done two time upon MailetContainer execution. When writing integration tests counting executions, that they were right! Tracking down the bug, I encountered that `MailImpl.duplicate` do not preserve state, hence processing resumes from ROOT processor (leaving the exchange). I first expected the fix to be easy: also duplicate the state (https://github.com/apache/james-project/pull/445 is an attempt in that direction). What was not my surprise to discover we actively rely on this bug... The MatcherSplit only keeps one mail after executing the current pair... My feeling is that matcher splitting always relied on this hack, and it back-fired. I reproduced the bug on code dating back from 2015. Thus considered that it was time to invest in a as complete as possible test suite enforcing the behavior of the mailet container flow. This can be seen here https://github.com/apache/james-project/pull/447. As my Camel skills are limited, I currently take the following actions: - Work on a plain java fix. My attempt at this can be seen here https://github.com/apache/james-project/pull/448 . Passes the test suite I did just write, it passes the whole test suite. - Contact the Camel PMC to see if someone is willing to help. - Walk through SVN history if possible to find the original author and go and ask him. - [what I am doing here] Trigger a discussion on the ML (server-dev) about dropping CAMEL. It could enable (eventually) writing reactive mailets <3. - Write an ADR about dropping Camel? The alternative approaches can be formulated: - Simplify the mailet container flow could split mails upfront and execute all recipients separately. This allows to trivially implement per recipient context (bye bye per recipients mailet/matchers) but it lead to duplicated execution of heavy-weight mailets and could have a significant impact for some users workload (eg doing content inspection for each recipient is a waste). - Pushing the hack of matcher splitter further. Split mail would instead of root be sent to their current processor. via attributes we could then skip pairs until where we were. Would solve the issue applying the exact same logic that today ones (splits starts a new execution). This is the closest to today behavior but I feel bad writing such pieces of code. Note that personally even if this behavior is critical for my clients, I can push their tailor made servers to use alternative mailet-container the time that the Apache James PMC agrees on a fix. Cheers, Benoit --------------------------------------------------------------------- To unsubscribe, e-mail: server-dev-unsubscr...@james.apache.org For additional commands, e-mail: server-dev-h...@james.apache.org
