Java Sélecteur de message pour obtenir un message de groupe de websphere mq

Question

J'essaie de recevoir un message de groupe d'un websphere mq 8 Queue Manager dans un mdb Java. Lors de l'obtention du LastMessageInGroup je reçois un jmsxgroupid comme 'ID: 45fdea5589' (getStringProperty) à partir du message. Quand je suis en train d'obtenir les autres messages de ce groupe, je suis sur un messageconsumer avec un messageselector où j'ajoute exactement le jmsxgroupid avec un jmsxsequence supplémentaire d'en haut, mais lorsque vous appelez la méthode receiveNoWait du messageConsumer je reçois un NullBytesMessage

la chose drôle est, lorsque le groupid est une chaîne lisible par l'utilisateur comme « » il fonctionne.

Donc cela fait partie du Code.
Nous recevons lastMessage dans la méthode onMessage de notre MDB.
Nous avons lu le JMSXGroupID de ce dernierMessage avec la méthode
String gid = lastMessage.getStringProperty ("JMSXGroupID"). Puis nous construisons un sélecteur pour obtenir le (s) autre (s) message (s) de ce groupe comme ceci:
String strSelector = "JMSXGroupID = '" + gid + "' ET JMSXGroupSeq = 1";
consumer = session.createConsumer (destIncoming, strSelector);
bmCurrentMessage = (BytesMessage) consumer.receiveNoWait();
Lorsque le gid est comme 'ID: 8d74b544d5862f32156cbfe845077c02d18ba33ac51c06aa' nous recevons un BytesMessage nul! Le mq agit comme si la file d'attente était vide.
Quand le gid est comme '20151015081515' nous recevons les autres messages du message de groupe!

Des conseils Que dois-je faire différemment?

Merci à ce jour pour la lecture Thomas

Answer 1

Bien après une longue période d'analyse avec les experts MQ d'IBM, nous avons dû installer un correctif fourni par IBM pour résoudre ce problème. Donc, il n'y avait évidemment aucun problème avec notre code mais un problème dans le code IBM du MQ Server 8 que nous utilisions.

Maintenant, le problème est résolu en installant la dernière version d'IBM.

Merci à tous pour avoir lu et réfléchi à mon problème!

Answer 2

Rappelez-vous que le GroupID, tout comme le MessageID et CorrelationID, n'est pas un champ de chaîne. Vous dites que cela fonctionne quand il s'agit d'une chaîne lisible par l'homme, ce qui implique que les temps où il échoue pour vous lorsque le GroupID n'est pas lisible par l'homme. Cela suggère que vous ne demandez pas le GroupID correct pour les messages suivants dans le groupe en raison du traitement de chaîne que vous avez effectué sur celui-ci. Traitez-le comme une chaîne d'octets et non une chaîne de caractères.