Objectif/Contenu :
Le but est de découvrir par la pratique deux aspects de JMS: le mode transactionnel pour une session, puis les Destinations de type topic.
Repartir du TP5, exercice 2 question 3. Ce programme simple envoie quelques messages dans la queue, qui sont consommés un à un (hormis ceux qui ne correspondraient pas à la condition passée via le sélecteur). Le mode utilisé pour acquitter un message étant Auto acknowledge, le client renvoie au MOM un tel ack à chaque fois qu'il retourne avec succès de la méthode onMessage (si nous avions utilisé un receive explicite, cet ack serait envoyé à la suite de chaque exécution terminée avec succès de la méthode receive()). La levée d'une exception (Runtime Exception) empêcherait donc l'envoi de l'ack.
Pour
simplifier, éliminer le second receiver du programme. Les messages
numérotés par un nombre pair sont donc ceux qui déclenchent l'exécution
de onMessage (vu que le sélecteur indique cette condition)du coté de
l'unique messageConsumer.
Par exemple, les messages de numéro égal à un multiple de 4 vont artificiellement provoquer une exception.
Laisser tourner votre programme suffisemment longtemps. Combien de fois semble-t-il que le MOM délivre un message non acquitté ?
Ce serait donc utile de savoir si un message est un message redélivré ou non; il est aisé de le savoir en consultant sa propriété JMS adéquate.
CorrectionEn mode transactionnel, l'envoi même transparent des accusés réception n'a plus lieu d'être. Au contraire, c'est l'exécution d'un commit() explicite qui permettra d'informer le MOM que les messages peuvent donc être retirés de la queue.
Commencez par enlever le sélecteur coté consommateur pour pouvoir recevoir les 10 messages produits par notre producteur. Et par déclarer que la session du consommateur est transactionnelle, mais laissez tel quel le reste du code. Cad, ne commitez pas.Videz bien la queue. Relancez le programme; Alors qu'il a produit des messages, et que ceux ci ont été consommés semble-t-il si l'on se fie aux print affichés par la méthode onMessage, mais que la consommation n'a pas été committée, la queue contient toujours tous ces messages (utiliser la console d'administration). Si on stoppe le programme, les messages produits sont bien effectivement dans la queue, leur consommation n'étant pas confirmée.
La délimitation des transactions se fait implicitement: (extrait de la spec JMS) A transaction is completed using either its session’s commit() or rollback() method. The completion of a session’s current transaction automatically begins the next. The result is that a transacted session always has a current transaction within which its work is done.
La transaction, englobant des opérations de réception de messages, va être commitée ou annulée selon le comportement possible suivant: réception de 5 messages déclenche un coup sur deux soit le commit, soit le rollback.
CorrectionModifier le code du producteur pour qu'il ne commite que les 5 premiers messages, les 5 suivants n'étant pas commités.
Testez et constatez que le consommateur n'en reçoit bien qu'un seul paquet de 5 messages alors que le producteur en a émis deux successifs mais n'a commité qu'un seul paquet.Essayez de comprendre les totaux de messages Enqueued et Dequeued sur
le topic, grâce à la console d'administration. En effet, le producteur a
peut-être produit des messages qui ne seront jamais notifiés si au
moment de leur publication, aucun souscripteur n'était actif !
Correction Publisher
Correction Souscripteur
Page maintenue par Francoise Baude @2014-