Hi, Sometime in the past, in the goal of having a fully-distributed James implementation, we decided that the embedded ActiveMQ was something to replace.
We studied a lot of solutions, ranging from having a standalone ActiveMQ server to implementing the MailQueue using RabbitMQ or Kafka. ActiveMQ looked not designed for dynamic clusters and we dropped that solution early. We hesitated a lot between RabbitMQ and Kafka as RabbitMQ is simpler to get started with but lack features and Kafka is on the other hand matching very well the requirements but was evaluated as hard to operate. We opted for RabbitMQ and invested a lot to have a working MailQueue by using Cassandra for features RabbitMQ lack. Currently, the result is starting to perform quite well. However, there are big drawbacks: * the complexity of the code is a bit crazy * the complexity of tuning is higher than we would like * RabbitMQ is not easy to put in cluster and has deciving characteristics (like not support network partition very well) * we didn't implement "delay" feature for RabbitMQ because there's no easy solution to that, what prevents this MailQueue implementation to be used for SMTP out (it would not handle delivery retries) We discussed recenlty about adding delay feature to it but as it would not make other points better and cost a lot to implement, I'm willing to debate alternatives. My opinion is that the messaging technology should not be a limiting factor now that we put the blobs out of it (it's a refactoring we did for RabbitMQ). We can probably handle thousand mails per second with a standalone ActiveMQ without any issue. Once the MailQueue is an scalability issue again, we could either evaluate back RabbitMQ or switch to Kafka or Pulsar. WDYT about that plan? -- Matthieu --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
