Discussion :

[joel.drigo]

Ça représente quoi ce booléen ? Une notion de succès/échec ? Une notion de traitement terminé, peu importe son statut ?

D'ailleurs, j'y pense, dans le code je t'ai indiqué, tu peux gérer une notion de timeout (avec countDownLatch.await(30, TimeUnit.SECONDS) par exemple pour avoir un timeout de 30 secondes), et dans ce cas tu peux gérer un booléen pour indiquer que le traitement est bien allé jusqu'au bout, ou que le message n'est jamais arrivé (enfin dans les 30 secondes) (ou gérer ça par exception)

[totot]

Pardons, je me suis trompé.
Dans onMessage, j'ai une autre variable qui est mi à jour, c'est le résultat du traitement.
Et ce résultat je veut le récupérer avec un getResultat() pour l'inclure dans la suite de mon programme principal

[joel.drigo]

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
16
17
18
19
20
21
22
23
24
25
26
27
28
public void faireTraitements(MessageConsumer receiver) {
CountDownLatch countDownLatch = new CountDownLatch(1); // on attend la fin de 1 traitement
 
AtomicReference<Resultat> resultatTraitements = new AtomicReferece<>();

receiver.setMessageListener( message-> {
 
     // traitement message...
 
     resultatTraitements.set(new Resultat(...));
     countDownLatch.countDown(); // le traitement est terminé
 
});
 
// traitements...
try {
   if ( countDownLatch.await(30, TimeUnit.SECONDS) ) { // on attend le message
           Resultat resultat = resultatTraitements.get();
           // autre traitements...
   }
   else {
          // le message n'est pas arrivé au bout de 30 secondes d'attente
   }
}
catch(InterruptedException e){
  //...
}
}

[tchize_]

pas besoin de tout ça pour attendre un message. Vous ête occupés de vous compliquer le bourrichon là. Une queue jms ça peux travailler pas listener (asynchrone) ou par receive (synchrone). Là vous êtes occupé d'utiliser le mode asynchrone et essayer de trouver un moyen de le rendre synchrone

Si tu a besoin d'avoir traité ton message pour continuer, remplace ton

Code :

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

1
2
3
4
public void lireMessage(){
//Connexion au serveur activeMQ
receiver.setMessageListener(this); // Permet d'appeler la méthode onMessage
}

par

Code :

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

1
2
3
4
5
public void lireMessage(){
//Connexion au serveur activeMQ
Message message = receiver.receive(); // Attends jusqu'à recevoir un message ou un timeout
traiter(message);
}

ainsi quand tu sortira de lireMessage, le message aura été traité.

[totot]

Le traitement du message est effectué par la méthode onMessage qui est appelé grâce à setMessageListener

[tchize_]

Ca je l'avais compris, je dis justement que c'est ce qu'il ne faut pas faire dans ton cas.

[joel.drigo]

Code :

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

1
2
3
4
5
 
[...]
Message message = receiver.receive(); // Attends jusqu'à recevoir un message ou un timeout
[...]
}

C'est sûr que s'il y a une méthode bloquante, c'est bien plus simple (je ne connais pas du tout ActiveMQ et son API, ceci explique cela).

[totot]

Et je souhaite rester sur l'utilisation de ma méthode onMessage

[tchize_]

il y a un besoin particulier? Parce que tu va vraiment te compliquer là vie entre: devoir attendre sur un Semaphore qu'un message soit traiter, la possibilité que non pas 1 mais 2 messages soient traité avant que tu ne reprenne la main, le risque que d'autre messages soient traités pendant que tu fais le reste de ton code, tu va devoir sortir une bonne grosse artillerie de code de synchronization.

[totot]

Pour l'instant je me concentre sur le fait qu'il y a un seul message et non deux et qu'il soient traiter tout seul, qu'il y en ait pas d'autre pendant mon traitement

[tchize_]

Pour l'instant je me concentre sur le fait qu'il y a un seul message et non deux et qu'il soient traiter tout seul, qu'il y en ait pas d'autre pendant mon traitement

Ouais, mais ça c'est pas la vraie vie. Tu ne peux pas garantir ça avec jms.