2008-10-17 10 views
9

Je suis à la recherche d'un framework de messagerie léger en Java. Ma tâche consiste à traiter les événements de la manière d'une SEDA: je sais que certaines étapes du traitement pourraient être complétées rapidement, et d'autres pas, et j'aimerais dissocier ces étapes de traitement. Disons que j'ai les composants A et B et que le moteur de traitement (que ce soit ce conteneur ou quoi que ce soit d'autre) invoque le composant A qui appelle le composant B. Je me fiche que le temps d'exécution du composant B soit 2s, mais attention si le temps d'exécution du composant A est inférieur à 50 ms, par exemple. Par conséquent, il semble plus raisonnable pour le composant A de soumettre un message à B, que B traitera au moment voulu.Messagerie légère (invocations asynchrones) en Java

Je connais différentes implémentations JMS et Apache ActiveMQ: elles sont trop lourdes pour cela. J'ai cherché une messagerie légère (avec des fonctionnalités vraiment basiques comme la sérialisation des messages et le routage le plus simple) en vain.

Avez-vous quelque chose à recommander dans ce numéro?

Répondre

4

Avez-vous besoin de toute sorte de persistance (par exemple, si votre JVM meurt entre le traitement de milliers de messages) et avez-vous besoin que les messages soient transmis à d'autres JVM? Si tout est dans une seule JVM et que vous n'avez pas besoin de vous inquiéter des transactions, de la récupération ou de la perte de messages si une JVM meurt - alors comme Chris l'a dit plus haut, les Executors vont bien.

ActiveMQ est assez léger; vous pouvez l'utiliser dans une seule JVM uniquement sans persistance si vous le souhaitez; vous pouvez ensuite activer les transactions/persistence/recovery/remoting (travailler avec plusieurs JVM) au fur et à mesure de vos besoins. Mais si vous n'avez besoin de rien de tout cela, alors utilisez les Executors. Incidemment, une autre option si vous n'êtes pas sûr des étapes qui pourraient nécessiter la persistance/fiabilité ou l'équilibrage de charge vers plusieurs JVM serait hide the use of middleware completely afin que vous puissiez basculer entre les files d'attente SEDA mémoire avec les exécutants vers JMS/ActiveMQ au fur et à mesure .

par exemple. il se peut que certaines étapes doivent être fiables (ce qui nécessite une sorte de persistance) et d'autres fois vous ne le faites pas.

4

Vraiment poids léger? Executors. :-) Donc vous configurez un exécuteur (B, dans votre description), et A soumet simplement des tâches à l'exécuteur.

2

Je pense que Apache Camel couvre tous vos besoins. Il fonctionne dans la JVM et prend en charge le style SEDA (http://camel.apache.org/seda.html) et le routage simpe. Peut être utilisé seul ou avec Spring, avec un fournisseur JMS ou d'autres adaptateurs.

1

Désolé de ressusciter un ancien thread, mais peut-être qu'il aide quelqu'un d'autre à le lire ... Je pense que FFMQ est un bon candidat pour un cadre de messagerie léger. MISE À JOUR: Cependant, je ne suis pas sûr si elle prend en charge les retards de livraison (le problème de la file d'attente des lettres mortes). Je trouverais cela utilisable même pour les fournisseurs légers. Mais je suppose que cela pourrait être possible avec une combinaison de requêtes MessageSelector et de propriétés de message.

0

Pour vous aider à quelqu'un d'autre lire ce fil:
L'un des plus léger cadre de messagerie est Mbasseder. MBassador est une implémentation de bus de message (événement) très légère qui suit le modèle de publication de souscription.Il est conçu pour être facile à utiliser et vise à être riche en fonctionnalités et extensible tout en préservant l'efficacité et la performance des ressources.
Le cœur de la haute performance de MBassador est une structure de données spécialisée qui minimise les conflits de verrous de sorte que la dégradation des performances de l'accès simultané est minime.
Caractéristiques: Définition de l'auditeur déclaratif via des annotations, la synchronisation et/ou la distribution d'événements asynchrones, les références faibles, le filtrage des messages

Questions connexes