Discussion :

[Moustikos]

Bonjour à tous,

J'ai un petit problème avec l'utilisation de JMS avec GlassFish.

Je m'explique :
J'ai deux queues (une de requete et une de reponse), mon client enverra un message sur la première où un message driven bean le recevra et le traitera. Jusque la, aucun problème tout marche nikel.

Cependant, lorsque mon MDB envoie sa réponse, il arrive (1 à 2 fois sur 3) que le message, qui devrait aller sur la file réponse, se retrouve sur la queue de requete et donc fait boucler mon MDB... (trace à l'appui).

Il semblerait que ce soit un probleme "physique" cad le support de mes queues qui est le même. Cependant, dès que je change ca en mettant dans le sun-ressources.xml des "physical queue" différentes,

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
 
<admin-object-resource enabled="true" jndi-name="Query" object-type="user" res-adapter="jmsra" res-type="javax.jms.Queue">
    <description/>
    <property name="Name" value="PhysicalQuery"/>
  </admin-object-resource>
  <connector-resource enabled="true" jndi-name="jms/QueryFactory" object-type="user" pool-name="jms/QueryFactoryPool">
    <description/>
  </connector-resource>
  <admin-object-resource enabled="true" jndi-name="Response" object-type="user" res-adapter="jmsra" res-type="javax.jms.Queue">
    <description/>
    <property name="Name" value="PhysicalResponse"/>
  </admin-object-resource>
  <connector-resource enabled="true" jndi-name="jms/ResponseFactory" object-type="user" pool-name="jms/ResponseFactoryPool">
    <description/>
  </connector-resource>

j'ai deux problèmes différents :

1) GlassFish ne me crée qu'une seule queue physique (visible via Interface web)
2) Mon MBD ne recoit plus les requetes.

Auriez vous une quelconque idée de ce qu'il se passe et comment le résoudre?

Merci

[bdidier]

bonjour,


le MDB consomme les messages mis a disposition par le broker sur sa queue, selon des parametres définis (lot de messages, mode d'accusé, etc)

et puis , un fois le message acquitté, on peut dire "c'est fini" d'un point de vue jms (message délivré et consommé)

il faut donc bien tester/valider cet aspect de consommation et choisir avec soin les comportements attendus (voir parametres suivants)

si ensuite , on prend la decision de "pousser" (envoyer/publier) le message recu (selon certains criteres (type pattern filter/pipe) c'est une *autre tache* ... presque "independante" (selon le niveau de transaction demandé)
de la precedente (donc le probleme est ailleurs)

il faut donc tester les deux fonctions separemment, puis integrer la "production" du message dans le MDB.

on trouve un petit outil fort sympathique avec OpenMQ (<GF_INSALL>\imq\demo\applications\uclient\UniversalClient.java) qui permet de produire/consommer des messages JMS pour mener les tests
on peut aussi le faire avec HermesJMS qui s'integre maintenant a OpenMQ (des articles existent (celui de Tom Barett , de tete))

@MessageDriven(mappedName = "jms/outQueue", activationConfig = {
@ActivationConfigProperty(propertyName = "acknowledgeMode", propertyValue = "Auto-acknowledge"),
@ActivationConfigProperty(propertyName = "destinationType", propertyValue = "javax.jms.Queue"),
...
...
})
public class SimpleMDBBeanBean implements MessageListener {

public void onMessage(Message message) {

try {

do something with the message

...

hth,
didier