Por ActiveMQ, ao contrário de um simples Fila / Mutex?

Question

Amanhã vou apresentar a minha razão para escolher uma implementação de fila de mensagens em processo, e eu sou incapaz de articular o meu raciocínio. Meus colegas de designers estão propondo que implementar uma fila assíncrona simples usando apenas uma lista básica de emprego e um mutex para controle de acesso, onde eu estou sugerindo ActiveMQ no modo incorporado. Eu pessoalmente sido muito impressionado com ActiveMQ, e eu gostaria de ter algum bom, argumentos sólidos para fazer backup de minha impressão intestino.

Se é importante, a aplicação é basicamente um produtor / n consumidores, com específica prioridade eo tipo de informação para os trabalhos individuais a ser processado.

É importante notar que até agora a capacidade de gerenciamento e extensibilidade da solução não ter sido argumentos poderosos. Eu adoraria se alguém poderia dar aos meus argumentos mais punch. Pode o fórum me ajudar com isso?

Answer 1

Seus colegas de trabalho argumentos não são sem mérito. Adicionando ActiveMQ para o projeto é a adição de mais uma dependência. Provavelmente será mais complicado de usar, e ele vai ter uma pegada maior do que uma solução personalizada. Também, desde que você está adotando, ele é provavelmente vai se tornar a sua responsabilidade de manter e continuar trabalhando sem problemas -. Erros e todos

Dito isso, ActiveMQ (e outras filas) vai fazer as coisas que você poderia escrever-se, mas pode vir a ser uma dor. Apoiando toda a API JMS é um deles (embora eu estou presumindo que você está usando Java ... se você não for, então este ponto não é válido). Serialização de mensagens em excesso em disco em situações de memória altos é outra. assinantes duráveis ??e seletores de mensagem são algumas outras coisas que vêm à mente. Principalmente sinos-e-assobios tipo de coisa para as suas necessidades ao que parece, mas tornam-se muito importante para a entrega de mensagens confiável.

Qualquer que você decidir, encapsular a escolha final do Message Broker longe do código de cliente para torná-lo mais fácil de switch.

Answer 2

Se a capacidade de gerenciamento e extensibilidade não são altas prioridades, então eu tenho que saber quais as razões para querer usar uma fila de mensagens administrável? Talvez seus colegas estão certos, e você realmente não precisa do conjunto de recursos extra?

Answer 3

Não ter que código de simultaneidade de depuração em casos extremos estranhas é um grande benefício. Eu não sei o quão importante esta estrutura é como parte de seu projeto geral, mas se a fila de mensagens é uma grande parte do seu projeto, então você pode colher tremendas benefícios usando uma implementação que alguém tem escrito, já depurado, e manterá para você. Se é apenas alguns one-off parte de um subsistema sem importância, ele provavelmente não importa o que você acaba fazendo. Mas se é crítica, eu prefiro um relatório de bug do que gastar o meu tempo a depuração do código de simultaneidade (eu já estou começando a recuo de medo!).

A versão curta: Não deixe que a síndrome NIH parar de usar o trabalho de outra pessoa para fazer o seu trabalho mais rápido, melhor e mais barato. Mas não construir uma montanha com um pequeno morro, qualquer um.