¿Por ActiveMQ, en contraposición a una cola sencilla / mutex?

Question

Mañana estoy presentando mi justificación de la elección de una aplicación de cola de mensajes durante el proceso, y soy incapaz de articular mi razonamiento. Mis compañeros de diseñadores proponen que ponemos en práctica un simple cola asíncrona utilizando sólo una lista básica de puestos de trabajo y un mutex para controlar el acceso, donde yo estoy sugiriendo ActiveMQ en modo incrustado. He estado personalmente muy impresionado por ActiveMQ, y me gustaría tener algunos buenos argumentos sólidos para respaldar mi impresión intestino.

si importa, la aplicación es básicamente 1 productor / n los consumidores, con prioridad y el tipo de información específica a los puestos de trabajo individuales que están siendo procesados.

Vale la pena señalar que hasta el momento la capacidad de administración y extensibilidad de la solución no han sido argumentos de peso. Me encantaría que si alguien podía dar mis argumentos más fuerza. ¿Puede el foro ayudarme con eso?

Answer 1

Sus compañeros de trabajo argumentos no carecen de fundamento. La adición de ActiveMQ al proyecto es la adición de una nueva dependencia. Probablemente será más complicado de usar, y que tendrá un impacto mayor que una solución personalizada. Además, dado que usted está adoptando ella, es probable que va a convertirse en su responsabilidad de mantener y seguir trabajando sin problemas -. Bichos y todo

Dicho esto, ActiveMQ (y otras colas) va a hacer las cosas que usted podría escribir usted mismo, pero podría llegar a ser un dolor. Apoyando a toda la API de JMS es uno de ellos (aunque Estoy suponiendo que está utilizando Java ... si no es así, entonces este punto no es válido). La serialización de mensajes exceso en el disco en situaciones de alto memoria es otra. suscriptores duraderos y selectores de mensajes son algunas otras cosas que vienen a la mente. Parcialmente campanas y silbatos-tipo de cosas para sus necesidades de lo que parece, pero se vuelven muy importantes para la entrega fiable de mensajes.

Lo decide, encapsular la elección final de intermediario de mensajes fuera del código de cliente para que sea más fácil de cambiar.

Answer 2

Si manejabilidad y capacidad de ampliación no son de alta prioridad entonces tengo que preguntarse cuáles son sus razones para querer utilizar una cola de mensajes manejable? Tal vez sus colegas tienen razón, y que realmente no necesitan el conjunto de características extra?

Answer 3

No tener que código de concurrencia de depuración en casos extremos extraños es un gran beneficio. No sé lo importante que es esta estructura como parte de su proyecto en general, pero si la cola de mensajes es una gran parte de su proyecto, a continuación, se puede cosechar tremendas beneficios mediante el uso de una implementación que otra persona ha escrito, ya depurado, y mantendrá para usted. Si es sólo una parte de una sola vez de un subsistema de poca importancia, es probable que no importa lo que terminan haciendo. Pero si es crítica, me gusta mucho prefiero un informe de error de gastar mi tiempo la depuración del código de concurrencia (ya estoy empezando a retroceder en el miedo!).

La versión corta: No deje que le impida el síndrome NIH de usar el trabajo de otro para hacer su trabajo más rápido, mejor y más barato. Pero no construir una montaña de un grano de arena, ya sea.