0

We are migrating applications from WebSphere Application Server Full profile (WAS) to Open liberty (OL)
One of the pattern we have is to consume a Queue in "strict FIFO order" for some JMS Queue. Many occurrences of the application are running concurrently ("cluster members" in WAS, "pods" in kubernetes/statefulset/docker for OL).
To implement FIFO, one and only one "JMS Activation" process/MDB can consume the Queue and if an exception occurs, stop the listener (JMS Activation)

In WAS, we can do this by

  • setting"WAS_EndpointInitialState"to"ACTIVE"on the JMS Activation for one server and"INACTIVE"for the others
  • set"Maximum server sessions"to 1 on the JMS Activation
  • check"Stop endpoint if message delivery fails"
  • monitor the logs to see if the activations stopped

In OL we can in"server.xml":

  • set"autoStart="true"on the"jmsActivationSpec" stanza for one of the process and "false"for the others
  • set"maxEndpoints="1"on the"jmsActivationSpec"

But how to make the activation stop in case of the application throw an exception in the"onMessage"method in the MDB?

[EDIT 1 After @JoshMc comment]
Currently, the message is moved to the DLQ and the activation never seem to stop, so FIFO is broken as the next message in the Queue is consumed...
Currently, when the "onMessage()"method throws an exception, the message is put back on the Queue, and immediately reprocessed, endlessly

The setting in"server.xml" to connect to IBM MQ from OL is done as decribed here

[EDIT 2]
This feature (stop the activation in case of failure) is implemented in IBM MQ rar v9.1.1 and WebSphere Liberty 18.0.0.4 by setting the "maxSequentialDeliveryFailures" property on the activation spec in this RFE. It does not work on Open Liberty v19.0.0.2 and IBM MQ rar v9.1.1. The rar specifically targets WebSphere Liberty to apply the property as cofirmed after activating traces on the connector:

March 7, 2019 1:17:38 EST PM[Default Executor-thread-7]     ResourceAdapterImpl
WMQ messaging : '9.1.1.0-p911-L181120.1'. 
MQJCA5003: 'maxSequentialFailureCount' cannot be set outside Websphere Liberty Profile

So the question is still there: How to make the activation stop in case of the"onMessage"method in the MDB fails to consume the message? Open a RFE to IBM MQ asking to port the feature to Open Liberty?

titou10
  • 2,814
  • 1
  • 19
  • 42
  • What are the values of BOTHRESH and BOQNAME for the local queue being consumed? – JoshMc Mar 07 '19 at 14:46
  • 1
    @JoshMc, BOTHRESH and BOQNAME were incorrectly sets. There are now BOQNAME ="" and BOTHRESH=0. Now the MDB loops forever failing and the activation is never stopped. I will edit my post – titou10 Mar 07 '19 at 15:10
  • In the trace can you tell "how" the RA is checking if it is running in Websphere Liberty Profile? In the case of how it is working now with BOTHRESH=0, is there a concern with it getting the message multiple times? As long as it is backed out you still maintain FIFO ordering. – JoshMc Mar 07 '19 at 21:21
  • @JoshMc in a sense you're right, FIFO should be maintained but the server is spinning on trying to consume the message with tons of logs, using cpu etc. The activation should "pause" as in WAS and in WebSphere Liberty,. – titou10 Mar 07 '19 at 21:57
  • I don't now "how" it detects WLP vs OL vs WAS. I spend some time "looking" in the rar itself and it would be difficult to override as the rar expects to find the JMX beans for the activation in a certain namespace, the namespace being different between WLP and OL. It uses the JMX Bean to "pause" or "resume" the MDB/activation for example if the`maxSequentialDeliveryFailures` is reached. So just cheat and find a way to "pretend" it is a WLP server, it will not work – titou10 Mar 07 '19 at 21:57
  • "pretend" is what I was going to suggest, but makes sense that it would not be "that" easy. – JoshMc Mar 07 '19 at 22:44
  • One other suggestion: `BOTHRESH(1) BOQNAME('')`, make sure the app does NOT have access to put to the DLQ, make sure the message is persistent. Note that the message can not have the reporting option `MQRO_DISCARD_MSG` either, but based on what you described previously this is not set or it would never have attempted to go to the DLQ. In the IBM KC page '[Removing messages from the queue in ASF](https://www.ibm.com/support/knowledgecenter/en/SSFKSJ_9.1.0/com.ibm.mq.dev.doc/q032680_.htm)" it documents the following: – JoshMc Mar 07 '19 at 22:49
  • "If a poison message cannot be requeued, perhaps because the dead-letter queue is full or authorization is wrongly specified, what happens depends on the persistence of the message. If the message is nonpersistent, the message is discarded and no report message is generated. If the message is persistent, delivery of messages to all connection consumers listening on that destination stops. Such connection consumers must be closed and the problem resolved before they can be re-created and message delivery restarted." – JoshMc Mar 07 '19 at 22:49
  • It may be a work around to what you want to accomplish. Worth a try. – JoshMc Mar 07 '19 at 22:49
  • @JoshMc I will test it monday. In the meantime I opened a ticket for Open Liberty: https://github.com/OpenLiberty/open-liberty/issues/6839 – titou10 Mar 08 '19 at 21:11
  • How did the testing go? Was interested to hear what happened :) – JoshMc Mar 11 '19 at 20:22
  • I don't know. It is quite difficult for me to be sure "that the app does not have access to the DLQ" for now. with`BOTHRESH(1)+BOQNAME('')` the message goes in the`SYSTEM.DEAD.LETTER.QUEUE`. For now we decided to split the application in 2, 1 onl;ine and one "infinite" batch and remove the MDB from the online app – titou10 Mar 12 '19 at 11:54
  • Does your application run as a user in the mqm group. On windows administrators also have full authority. – JoshMc Mar 12 '19 at 14:30

0 Answers0