Discussion :

[tchize_]

Bonjour,

je coince sur un petit problème pour un unit test. J'ai un paquet de MDB qui s'inscrivent sur une topic, un truc dans ce genre là:

Code :

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

1
2
3
4
5
6
7
8
9
10
11
@MessageDriven(activationConfig = {
    @ActivationConfigProperty(propertyName = "destinationType", propertyValue = "javax.jms.Topic"),
    @ActivationConfigProperty(propertyName = "destination", propertyValue = "topic/someTopic"),
    @ActivationConfigProperty(propertyName = "maxSession", propertyValue = "1"),
    @ActivationConfigProperty(propertyName = "subscriptionDurability", propertyValue = "Durable"),
    @ActivationConfigProperty(propertyName = "subscriptionName", propertyValue = "XYZHandlerEJB3"),
    @ActivationConfigProperty(propertyName = "clientId", propertyValue = "XYZHandlerEJB3") })
public class XYZHandler implements MessageListener {
 
  @Override
  public void onMessage(Message message) {

J'ai de l'autre coté des unit test qui font actuellement ceci:

• poster un message sur la queue
• attendre 1 secondes
• s'assurer que l'état de la DB correspond à ce qui est attendu après traitement

multiplié par le nombre de tests, on est de l'ordre de 30 minutes pour lancer les tests sur les MDB. Sachant qu'on attends 1s quelque chose qui s'exécute typiquement en 20/30ms, y a de la perte de temps. J'avais pensé créer un MDB de test qui, lorsqu'il reçoit le message, abaisse un flag pour dire au unit test "message reçu". Mais non, les MDB s'exécutant en parallèle, mon MDB ne bloque pas l'exécution des autres, et les autres ne bloquent pas le mien. Du coup ce n'est pas parce que j'ai reçu le message que c'est traité...

Je voudrais savoir quelles seraient les alternatives. Est-il possible d'empêcher le parallélisme entre les MDB? De garantir un ordre d'execution des MDB (genre le MDB test uniquement quand les autres ont fini)? De savoir quand un message a été entièrement traité? Enrober mes MDB avec des post message hooks durant le test (et comment)?

Je précise que je peux rajouter des MDB supplémentaire, je peux jouer sur la config de la queue (c'est du Hornet MQ), jouer sur la config ejb3 utilisée par le unit test. Par contre l'option d'aller rajouter du code dans les MDB buisness n'est pas acceptable, ils doivent être performant et, par exemple, rajouter une queue de ack les rendrait trop lents. Ensuite, d'une manière général, je ne veux pas de code ne servant qu'aux tests dans la partie buisness.

[tchize_]

Bon bon bon, il y a du nouveau.

J'arrive à catcher la fin des MDB en utilisant des EJB3 interceptor. Soucis restant: quand mon interceptor reprend la main après le onMessage, on est toujours dans la transaction. Mon interceptor envoie ensuite un message sur un autre queue, qui est réceptionné et traité... avant que l'EntityManager du premier bean n'ai fait son commit. Un poil de milliesoncdes trop tôt donc. J'avais pensé qu'en repassant par une queue j'ai pas ce problème, mais si. Il semble que le deuxième MDB qui écoute les messages lancé par l'interceptor, reçoive le message alors même que la transaction de l'interceptor n'est pas cloturée. Comment est-ce possible? Je pensais qu'en CMP, le message ne pouvait pas partir avant le commit?

pour schématiser, j'ai ceci:

Code x :

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

1
2
3
unit test => message Topic1 => wait sur semaphore                                                                                                    //=> Reprise => Données pas présentes dans DB
             ||                                                                                                   //=> MDB2.onMessage() => libérer le sémaphore 
             \\=> Interceptor MDB1 => MDB1.onMessage() (avec de l'entitymanager et tout) => Interceptor MDB1 => message vers Topic 2 ===========================================================> update DB par entitymanager

[Desboys]

Salut Tchize_,

Si j'ai bien compris, tu veux pouvoir détecter la fin de processing asynchrone pour en vérifier le résultat en DB.
Le truc qui me vient naïvement, c'est:

• top dans une table technique lié au protocole de test en fin de traitement MDB ( via interceptor pour ne pas toucher ton business code ).
• le bloc de test fait un "polling" de la table de test pour pouvoir lancer la vérification ( post -> poll -> verify ).

Avec un identifiant en JMSProperty qui pourrait être une "clef de corrélation" entre ton traitement et ton test, par exemple.

Cordialement,
Sébastien

[tchize_]

J'ai trouvé et oublié de poster finalement.


Alors d'abord, si on avait le deuxième message avant le commit, il semblerait que ce soit du à une particularité de jboss embedded qu'on utilise pour les tests: JMS n'y est pas transactionnel pour l'envoi de nouveaux messages

Ensuite, j'ai résolu le problème du "c'est bon, fini tu peux reprendre la main" en injectant dans l'interceptor le TransactionManager via un @Resource et en faisant

Code :

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

1
2
3
transactionManager.getTransaction().registerSynchronization(new Synchronization(){
//... et on fait le job dans le afterCompletion() ;)
});

J'avais pensé aussi la à DB, mais du coup on ne reçois pas le TOP de fin si la transaction est annulée. Hors on pourrait vouloir s'assurer que l'action JMS a été refusée