james-server-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "btellier@apache.org" <btell...@apache.org>
Subject Major bug: Camel mailet container and partial matches.
Date Sat, 22 May 2021 06:24:13 GMT
Hello folks,

I want to raise this concern to the mailing list.

As described in

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.



To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org

View raw message