Liberty Profile on z/OS provides the way to surface resource adapter health

The concern is that ServerEndpointControl.isActive() continues to return true even after all reconnection attempts have failed and the MDB is no longer able to consume messages.

The updated problem statement is described below.

Environment
The MDB is configured with an ActivationSpec and uses IBM MQ as the JMS provider.
The Liberty configuration contains the following MQ JMS client settings:

<variable name="wmqJmsClient.rar.location"
value="/Users/kenoi/wlp/usr/shared/resources/mq/wmq.jmsra.rar"/>
 
<wmqJmsClient reconnectionRetryCount="3"
reconnectionRetryInterval="30s"/>

Based on these settings, the ActivationSpec is expected to attempt reconnection three times with a 30-second interval between attempts.

Scenario

1. The MDB is running normally and consuming messages from MQ.

2. The queue manager is stopped.

3. The ActivationSpec detects the connection failure and starts its reconnection attempts.

4. The reconnect behavior matches the configured values (3 retries with a 30-second interval).

5. After the configured retries are exhausted, the following messages are observed:

[10/1/26, 10:54:14:561 JST] 000000d1 WMQ.commonservices.trace                                     I Activation specification reconnection attempt '1' of '3'.  Waiting '30000' milliseconds before attempting to reconnect the endpoint 'javax.jms.Queue:queue://QM1/DEV.QUEUE.2@QM1 <2132164291>'.

[10/1/26, 10:54:44:755 JST] 000000d1 WMQ.commonservices.trace                                     I Activation specification reconnection attempt '2' of '3'.  Waiting '30000' milliseconds before attempting to reconnect the endpoint 'javax.jms.Queue:queue://QM1/DEV.QUEUE.2@QM1 <2132164291>'.

[10/1/26, 10:55:14:952 JST] 000000d1 WMQ.commonservices.trace                                     I Failed to reconnect one or more MDBs after a connection failure.

At this point, all reconnection attempts have been exhausted and MDB message processing stops because the connection to MQ can no longer be established.

Observed Behavior

Although the MDB is no longer able to process messages and all configured reconnection attempts have failed, the endpoint status still reports as active.

The following JMX operation returns true:

curl -u $ADMIN -k -X POST \
-H "Content-Type: application/json" \
-d '{"params":[{"value":"jms#jms.war#PdprofMdb","type":"java.lang.String"}],"signature":["java.lang.String"]}' \
$SERVER_URL/IBMJMXConnectorREST/mbeans/WebSphere%3Afeature%3Dkernel%2Cname%3DServerEndpointControl/operations/isActive

Response:

{"value":"true","type":"java.lang.Boolean"}

Concern
Once all reconnection attempts configured by:

<wmqJmsClient reconnectionRetryCount="3"
reconnectionRetryInterval="30s"/>

have been exhausted, MDB message consumption is no longer possible. From an operational perspective, the endpoint is effectively unavailable.

However, ServerEndpointControl.isActive() continues to return true, indicating that the endpoint is active even though it can no longer receive or process messages.

This discrepancy between the actual runtime capability of the MDB and the reported endpoint status can lead to misleading monitoring results. Operational tools may interpret the MDB as healthy and available while it is in fact unable to consume messages.

Request

We would like to request a change to the endpoint status behavior. Once all configured reconnection attempts have been exhausted and MDB message consumption is no longer possible, the endpoint status should reflect the actual operational state of the MDB rather than continuing to report the endpoint as active.