Hi Matthieu, My answers are inlined.
On 20/04/2020 16:25, Matthieu Baechler wrote: > Hi, > > [...] > > We studied a lot of solutions, ranging from having a standalone ActiveMQ server to implementing the MailQueue using RabbitMQ or Kafka. Why we chose RabbitMQ deserves an ADR don't you think? > [...] > > However, there are big drawbacks: > > * the complexity of the code is a bit crazy I don't by it. A time serie with applicative tombstones is not something complicated to me. > * the complexity of tuning is higher than we would like Maybe the settings correspond to the code technicity and not correlated to the administrator experience thus requiring the administrator to understand the way the solution works. A way around this issue could be having configuration reflecting admin expectations like: - Count of Cassandra servers - Maximum mail throughtput. Our technical parameters could then been derived from the supplied values. Technical values could still be exposed for advanced users BTW. > * 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) I proposed https://issues.apache.org/jira/browse/JAMES-2896 which sounds achievable given reasonable enhancement. Can you explain to me why such a solution would not be doable to you? Maybe discussing it in the issue.... > > 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. I don't know pulsar enough but I don't think Kafka could handle all administrative operations (especially arbitrary deletion) by itself. IMO the gain on the complexity aspect would be limited. > WDYT about that plan? I'm never against people willing to explore alternatives. However we might then cosider fully remove rabbitMQ support, thus for the EventBus implementation and for the distributed task manager, in order not to ship a product with two messaging dependencies. Regards Benoit --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
