Hello dear James committers, In the absence of further feedback I will proceed with sanitizing the [1] proof of concept, to turn it into a full removal of Camel.
Cheers, Benoit On 24/05/2021 11:50, Rene Cordier wrote: > Hi Benoit, > > Thanks for raising this concern it's rather interesting, despite my > limited knowledge on Camel processing and MailetContainer execution. > > I think if we can come up with a robust Java implementation allowing > to discard yet an other dependency (Camel) from James, that would be a > win already, as we should keep trying to trim the number of them down. > > If also it allows at some point to have reactive mailets it would be > an other win. > > So I would be in offer of your proposition. > > Regards, > Rene. > > On 22/05/2021 13:24, btell...@apache.org wrote: >> 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 >> >> > > --------------------------------------------------------------------- > To unsubscribe, e-mail: server-dev-unsubscr...@james.apache.org > For additional commands, e-mail: server-dev-h...@james.apache.org > > --------------------------------------------------------------------- To unsubscribe, e-mail: server-dev-unsubscr...@james.apache.org For additional commands, e-mail: server-dev-h...@james.apache.org
