You are viewing a plain text version of this content. The canonical link for it is here.
Posted to server-dev@james.apache.org by Benoit TELLIER <bt...@apache.org> on 2022/05/09 11:15:14 UTC
Faight of cassandra-app artifact?
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-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
Re: Faight of cassandra-app artifact?
Posted by Benoit TELLIER <bt...@linagora.com>.
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-unsubscribe@james.apache.org
>> For additional commands, e-mail: server-dev-help@james.apache.org
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
> For additional commands, e-mail: server-dev-help@james.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
Re: Faight of cassandra-app artifact?
Posted by Matthieu Baechler <ma...@apache.org>.
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-unsubscribe@james.apache.org
> For additional commands, e-mail: server-dev-help@james.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org