Discussion :

[Hole_geek]

Bonjour,

Je suis en train d'étudier l'API JMS et je me pose quelques questions. J'espère que vous pourrez m'éclairer sur quelques points

Je lis qu'une des nouveautés de la version 2.0 de JMS propose l'envoi de message asynchrone.
Cela veut-il dire qu'en version 1.1, le Producer attendait de recevoir un acquittement avant de poursuivre l’exécution qui suit le "send" (synchrone) ?

La version 2.0 propose-t-elle l'envoi synchrone de message ? Si oui, comment distingue-t-on les deux modes ?

Merci par avance pour vos infos

[manipas]

Concernant l'envoi de messages avec JMS 2.0, il n'y a pas de difference entre les 2 modes.
L'objet JMSContext qui remplace les objets Connection et Session des versions precedentes sera utilise pour creer le context, le producteur (ie ton application) et envoyer le message

JMSContext context = connectionFactory.createContext();
context.createProducer().send(msg_queue, mon_msg)

La grande difference se trouve lors de la reception de message sync et async
ASYNC: creer un objet JMSConsumer et setter un listener qui ecoutera l'arrivee des nouveaux messages, puis executera ta methode onMessage();
JMSConsumer consommateur = context.createConsumer(msg_queue);
consommateur.setMessageListener(messageListener);

SYNC : consommer les message en ecoutant directement la msg queue a partir de la session
JMSContext context = connectionFactory.createContext();
JMSConsumer consumer = session.createConsumer(msg_queue);
body = consumer.receiveBody(<message_type>);

[Hole_geek]

Donc l'envoie d'un message avec JMS 2 est toujours asynchrone ?

Si c'est le cas, j'me pose une question.
Ex :
Un producteur envoie un message dans une Queue avec JMS 2. Le consommateur rencontre une exception durant le traitement de ce message.
Comment avertir le producteur qu'une exception a été rencontré dans le traitement du message envoyé ?

Merci par avance pour vos explications.

[manipas]

Le principe de JMS est que le producteur et le(s) consommateur(s) ne se parlent pas directement.
La communication est faite via un message queue (dans le cas du point-to-point) ou topic (dans le du publish-subscribe).
Donc le producteur n'attend rien du consommateur et n'est meme pas au courant de ce que le consommateur va faire du message qu'il met dans le msg queue ou topic.
Le producteur depose son message et n'attend pas la reponse. Le consommateur peut ne pas fonctionner mais le message est toujours present dans la queue, quand il redevient UP il va les consommer.

Utiliser JMS de maniere synchrone n'est pas la meilleure chose a faire, mais son efficacite est tres grande lorsqu'il est utilise de maniere asynchrone. L'objectif premier de JMS quelque soit la version est de faciliter l'envoi des messages de maniere asynchrone.

Si le consommateur rencontre une exception durant le traitement d'un message, le message est remis dans la queue pour reessayer a nouveau, le nombres d'essais depend de la configuration faite au niveau du serveur d'application lors de la creation de la message queue. Ou bien le message est mis dans la dead message queue, et la le service de support va lire le dead message queue pour prendre actions. Ou encore lors de la configuration on peut utiliser l'option Persistent pour persister les messages pour qu'ils ne se perdent pas.

Il y a aussi dans publish-subscribe les combinaisons d'options suivantes : Persistent & Durable, Non Persistent & Durable, Persistent & Non Durable, Non Persistent & Non Durable