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
