Coda ordinaria contro coda SEDA

Question

Essendo nuovo per Apache Camel, di recente ho esaminato la lunga lista di componenti e sono incappato nel supporto per i componenti SEDA queue.

La pagina non aveva molto senso per me, quindi ho fatto un paio di ricerche online per il termine "coda SEDA" e ho ottenuto l'articolo di wikipedia here.

Dopo aver letto quell'articolo, non posso dire quale sia la differenza tra una coda SEDA e una normale coda "ordinaria"! Entrambi abbracciano la nozione di sistemi di disaccoppiamento attraverso l'uso di code asincrone.

Dall'articolo, "SEDA" suona come un'architettura che consiste nel mettere una coda tra ciascun componente. È corretto?

Ma se è solo un'architettura, perché una coda "SEDA" è un componente speciale di Apache Camel?

Answer 1

Le code SEDA sono come una normale coda (e come detto in precedenza da Peter, in Camel hanno un pool di thread associato a loro come parte del componente). SEDA è un'architettura. Il componente SEDA in Camel utilizza le code in memoria nel processo e sono un componente separato per distinguerle dall'altro componente della coda nel cammello Apache, ovvero il componente JMS.

Answer 2

SEDA offre il disaccoppiamento dei componenti all'interno di un unico percorso di cammello. O per quanto riguarda all'interno di un singolo processo. . Significa che ti aiuta a effettuare chiamate asincrone ad altri componenti ... è un blocco in memoria. D'altro canto JMS è utilizzato per il disaccoppiamento di tutto il sistema .. JMS avranno un broker esterna coinvolto .. SEDA willl basta creare un thread separato dal componente consumatore

Answer 3

SEDA è un acronimo che significa evento organizzato Driven Architecture è progettato come un meccanismo per regolare il flusso tra diverse fasi di elaborazione dei messaggi. L'idea è di appianare la frequenza dell'output dei messaggi da un processo generale in modo che corrisponda all'input, Permette ai thread dei consumatori di un enpoint di scaricare il lavoro delle operazioni a lungo termine nel bakground, liberandoli così fino a consumare messaggi dal trasporto. Quando uno scambio viene passato a un seda: endpoint, viene inserito in un BlockingQueue. L'elenco esiste all'interno del contesto cammello, il che significa che solo quelle route che si trovano nello stesso contesto possono essere raggiunte da questo tipo di endpoint. La coda è illimitata per impostazione predefinita, sebbene possa essere modificata impostando l'attributo size sull'URI del consumatore.

Per impostazione predefinita, un singolo thread assegnato all'endpoint legge gli scambi dall'elenco e li elabora attraverso il percorso. Come visto nell'esempio procedurale, è possibile aumentare il numero di concurrentConsumers per garantire che gli scambi vengano elaborati da tale elenco in modo tempestivo.

Il modello SEDA è più adatto all'elaborazione dei messaggi InOnly, in cui un percorso termina l'elaborazione e consegna a un altro per affrontare la fase successiva. è possibile chiedere una risposta da seda: endpoint chiamandolo quando il modello di scambio messaggi è InOut

Riferimento. Apache Camel Developer's Cookbook