Thanks for the reply.
Unless further feedback is provided, I propose to:
- Open a JIRA to disable mail queue management for the distributed
mail queue
- Open a JIRA to track this deprecation/removal
- Open a PR depracating this artifact
- Plan the removal on master after 3.8.0 release
Best regards,
Benoit
On 16/05/2022 13:05, Matthieu Baechler wrote:
Hi Benoit,
I agree this artifact should be removed as there's no good use-case for
it.
Cheers,
-- Matthieu
On Mon, 2022-05-09 at 18:15 +0700, Benoit TELLIER wrote:
Hello all,
That is quite some time I actively militate against the cassandra-
app.
Here are issues I have with this artifact:
- It is not targeting distributed deployment. Because it do not
leverages messaging technologies, it only supports one application
server in order to be able to implement connected protocols like
IMAP.
- Cassandra + ElasticSearch are difficult/expensive to operate
systems. Having them with only one application server is overkill.
- The two above points creates confusion and some of my customers
missed the "limitation section" and run into troubles.
- The Cassandra blob store sucks. Period.
-> Everything is written to one huge SSTable - beware of
exceeding
50% of node storage!
-> Cassandra compaction takes forever and depletes cassandra node
ressources (off-heap memory)
-> Cassandra storage is expensive
-> The horror story further develops but I am uneasy to share
this
publicly as some fixes were clear Cassandra anti-patterns.....
- Some emails can get stuck in ActiveMQ - I was unable to come up
with
a proper diagnostic for this and some oldish issues already tend to
refer to this behaviour.
- This artifact is accidental: merely a step toward the distributed
server that we never got rid of.
- Too many artifact is complexity, build time... I would be happy
to
remove this one to let the room for other artifacts to shine.
My proposal is thus to deprecate / remove it.
Migration to the distributed server can be done with only one added
dependency (RabbitMQ) and no data loss given that the mail queue is
empty.
Some project members have expressed concerns regarding the current
distributed application and its rabbitMQ mail queue. The "management"
part of this mail queue was implemented in cunjunction with Cassandra
and lead to complex code that is hard to maintain and hard to
operate.
The "delay" feature (that makes management features needed!) is not
supported. On the long term the project expressed its interest for
having a Pulsar based distributed server. However on the short term,
and
in order to support this deprecation, I propose to allow simplifying
the
RabbitMQ by adding an option not to activate "management features".
Given that is behaves as a pure message queue (no delays), for a MDA
looking into and interfering with a mail queue makes little sense
(and I
never did). Adding an option to drop this complexity, disable
browse/flush/size/remove/clear would allow to have a simple yet
reliable
mail queue suited to a MDA in the waiting of the Pulsar alternative.
Thoughts?
Best regards,
Benoit TELLIER
---------------------------------------------------------------------
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
