1

We are using Websphere MQ8 and thinking about using durable Topics to implement a Publish and Subscribe pattern.

We are using Queues already and Hermes JMS-Browser to correct erroneous Queue-Messages.

I know that you can use Hermes to subscribe to topics but i think you cannot access and modify messages that are already on hold for a specific client.

So I would like to know - how do you handle problems when there are durable messages for a specific client application that the client can't consume, e.g. because the message has wrong format?

Do you have to delete alle undelivered messages for this client? Or is there some tooling that can do this?

Dirk
  • 1,064
  • 1
  • 11
  • 13

1 Answers1

0

How do you handle problems when there are durable messages for a specific client application that the client can't consume, e.g. because the message has wrong format ?

Consuming Application (Client) should have proper exception handling and it should throw out all bad/poison messages.

Do you have to delete all undelivered messages for this client? Or is there some tooling that can do this?

The messages will be deleted automatically by the MQ server once the TTL (Time To Live) expires. We can't manually delete those messages as they belong/meant for the original client (which is a durable subscriber).

The below link explains well on the concept of JMS durable subscriptions: https://docs.oracle.com/cd/E19798-01/821-1841/bncgd/index.html

Also I have provided the below sample code for the tool, which logs (doesn't delete) the messages from a durable subscription topic:

   InitialContext ctx = new InitialContext();
   Topic topic = (Topic)ctx.lookup("myJMSTopic1");

   TopicConnectionFactory connFactory = (TopicConnectionFactory) ctx.lookup("topicConnFactory");
   TopicConnection topicConn = connFactory.createTopicConnection();
   topicConn.setClientID("myToolId1"); //Use a different client id than original subscriber

   TopicSession topicSession = topicConn.createTopicSession(false, Session.AUTO_ACKNOWLEDGE);

   TopicSubscriber topicSubscriber = topicSession.createDurableSubscriber(topic, "myClientExistingDuraSubName"); // this is where you have to provide the original client's durable subscription name

   while(true) {
        Message message = topicSubscriber.receive();
        TextMessage txtMsg = (TextMessage)message;
        logger.info(txtMsg.getText());
   }
Vasu
  • 21,832
  • 11
  • 51
  • 67
  • My problem is that when you are getting a XA Transaction rollback e.g. from your database, you are not able to remove the poisoned message anymore, right? The Topic will rollback, too in this case. Then some Tooling would be nice. Sounds like a pretty common problem to me, so wondering that there is no standard solution for it... – Dirk Sep 17 '15 at 22:03
  • I got your point, can you add the code (in your query) of your MDB method which has this XATransaction code ? – Vasu Sep 18 '15 at 09:33
  • Right now we have MDBs listening to queues and writing into a database afterwards. But the code will be very similar when listening to topics. What is your idea? – Dirk Sep 19 '15 at 12:08