[
https://issues.apache.org/jira/browse/JAMES-3589?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17349605#comment-17349605
]
Benoit Tellier commented on JAMES-3589:
---------------------------------------
It seems pretty bad to me, https://github.com/apache/james-project/pull/445
failed at finding an easy fix to the issue...
I 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.
My feeling is that matcher splitting always relied on hack, and it back-fired.
I reproduced the bug on code dating back from 2015.
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, let's see if it makes it thought-out 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.
- Trigger a discussion on the ML (server-dev) about dropping CAMEL. It could
enable writing reactive mailets <3.
- Write an ADR about dropping Camel.
The alternative approaches can be formulated:
- Simplify the mailet container flow to 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
behaviour but I feel bad writing such pieces of code.
Note that personnaly even if this behaviour 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
> Matched mail resume processing from root
> ----------------------------------------
>
> Key: JAMES-3589
> URL: https://issues.apache.org/jira/browse/JAMES-3589
> Project: James Server
> Issue Type: Bug
> Components: MailStore & MailRepository
> Affects Versions: 3.5.0, 3.6.0
> Reporter: Benoit Tellier
> Priority: Major
> Fix For: 3.7.0, 3.6.1
>
> Time Spent: 50m
> Remaining Estimate: 0h
>
> h3. What
> One of my customer reported me that a side effect was done two time upon
> MailetContainer execution.
> What was not my surprise 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).
> h3. The fix
> MatcherSplitter should preserve the state of the matched mail.
> h3. The complications
> Preserving several mails on the same exchange, we should not shut the
> exchange down before processing is finished. Doing so would result in
> following I did set up reference counting for this.
--
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
