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
