Queue ordinaire vs SEDA Queue

Question

Étant nouveau à Apache Camel, j'ai récemment passé en revue sa longue liste de composants et suis tombé sur leur support pour les composants SEDA queue.

La page n'a pas beaucoup de sens pour moi, donc j'ai fait quelques recherches en ligne pour le terme "SEDA queue" et j'ai obtenu l'article wikipedia here. Après avoir lu cet article, je ne peux pas dire quelle est la différence entre une file d'attente SEDA et une file d'attente "ordinaire" normale! Les deux embrassent la notion de systèmes de découplage par l'utilisation de files d'attente asynchrones. Dans l'article, "SEDA" ressemble à une architecture qui consiste à placer une file d'attente entre chaque composant. Est-ce correct?

Mais si c'est juste une architecture, alors pourquoi une file d'attente "SEDA" est-elle un composant spécial d'Apache Camel?

Answer 1

Les files d'attente SEDA sont comme une file d'attente régulière (et comme Peter l'a dit plus haut, dans Camel, un pool de threads leur est associé comme faisant partie du composant). SEDA est une architecture. Le composant SEDA dans Camel utilise des files d'attente en mémoire dans votre processus et constitue un composant distinct afin de les distinguer de l'autre composant de file d'attente dans Apache camel, à savoir le composant JMS.

Answer 2

SEDA offre le découplage des composants au sein d'une seule voie de dromadaire. Ou d'ailleurs dans un seul processus. . Ce qui signifie qu'il vous aide à effectuer des appels asynchrones à d'autres composants ... c'est une mémoire bloquante. autre JMS main est utilisé pour le découplage de l'ensemble du système .. JMS aura un courtier externe impliqué .. SEDA willl il suffit de créer un thread séparé de la composante des consommateurs

Answer 3

SEDA est un acronyme qui signifie événement Mise en scène Driven Architecture il est conçu comme un mécanisme pour réguler le flux entre les différentes phases du traitement des messages. L'idée est de lisser la fréquence de sortie du message d'un processus global afin qu'il corresponde à l'entrée. Il permet aux threads de consommation d'un point de décharger le travail des opérations de longue durée dans le bakground, les libérant ainsi pour consommer des messages. du transport. Lorsqu'un échange est passé à un seda: endpoint, il est placé dans un BlockingQueue. La liste existe dans le contexte de camel, ce qui signifie que seules les routes qui sont dans le même contexte peuvent être jointes par ce type de point de terminaison. La file d'attente est illimitée par défaut, bien que cela puisse être changé en définissant l'attribut size sur l'URI du consommateur.

Par défaut, un seul thread affecté au noeud final lit les échanges hors de la liste et les traite via l'itinéraire. Comme on peut le voir dans l'exemple de procédure, il est possible d'augmenter le nombre de comptes concurrenct pour s'assurer que les échanges sont traités à partir de cette liste en temps opportun. Le modèle SEDA est le mieux adapté au traitement des messages InOnly, où une route finit le traitement et passe à l'autre pour traiter la phase suivante. il est possible de demander une réponse de seda: endpoint en l'appelant quand le pattern d'échange de messages est InOut

Référence. Cookbook du développeur Apache Camel