Perché ActiveMQ, al contrario di una semplice coda / Mutex?

Question

Domani sto presentando la mia motivazione per la scelta di un'implementazione coda di messaggi in-process, e sono in grado di articolare il mio ragionamento. Il mio co-designer propongono che implementiamo una semplice coda di asincrona utilizzando solo una lista di base di posti di lavoro e un mutex per controllare l'accesso, dove sto suggerendo ActiveMQ in modalità incorporata. Ho personalmente stato molto impressionato da ActiveMQ, e vorrei avere alcune buone, solidi argomenti per eseguire il backup mio intestino impressione.

Se è importante, l'applicazione è fondamentalmente 1 produttore / n consumatori, con priorità e digitare le informazioni specifiche per i singoli lavori in corso di elaborazione.

Vale la pena notare che finora la gestibilità ed estendibilità della soluzione non sono stati forti argomenti. Mi piacerebbe se qualcuno potesse dare i miei argomenti più punch. Può il forum aiutarmi con questo?

Answer 1

I tuoi colleghi argomenti non sono senza merito. Aggiunta di ActiveMQ al progetto è l'aggiunta di un ulteriore dipendenza. Probabilmente sarà più complicato da usare, e avrà un impatto maggiore di una soluzione personalizzata. Inoltre, dal momento che si stanno adottando esso, è probabile che a diventare la vostra responsabilità di mantenere e continuare a lavorare senza intoppi -. Bug e tutti

Detto questo, ActiveMQ (e altre code) farà cose che si potrebbe scrivere da soli, ma potrebbe rivelarsi un dolore. Sostenere l'intera API JMS è uno di loro (se sto presumendo che si sta utilizzando Java ... se non siete, allora questo punto non è valido). Serializzazione di messaggi in eccesso sul disco in situazioni di memoria ad alta è un altro. abbonati durevoli e selettori dei messaggi sono alcune altre cose che vengono in mente. Per lo più campane e fischietti genere di cose per le vostre esigenze a quanto pare, ma diventano molto importante per la consegna dei messaggi affidabile.

Qualunque cosa tu decida, incapsulare la scelta finale del broker di messaggi dal codice client per rendere più facile per passare.

Answer 2

Se la gestibilità ed estendibilità non sono alti priorità, allora mi chiedo che cosa i vostri motivi sono per voler usare una coda di messaggi gestibile? Forse i vostri colleghi sono a destra, e davvero non hanno bisogno del set di funzionalità in più?

Answer 3

Non dover eseguire il debug di codice concorrenza nei casi limite strani è un grande vantaggio. Non so quanto sia importante questa struttura è la parte del progetto complessivo, ma se la coda di messaggi è una grande parte del vostro progetto, allora si possono trarre tremendi vantaggi utilizzando un'implementazione che qualcun altro ha scritto, già debug, e manterrà per voi. Se è solo una parte una tantum di un sottosistema di poco importante, probabilmente non ha importanza quello che si finisce per fare. Ma se è importante, mi piacerebbe molto piuttosto un bug report di passare il mio tempo debug del codice della concorrenza (Sto già cominciando a indietreggiare nella paura!).

La versione corta: Non lasciare che la sindrome NIH ti impedisca di utilizzare il lavoro di qualcun altro per ottenere il vostro lavoro fatto più veloce, migliore, e più economico. Ma non costruire una montagna da un granello di sabbia, sia.