Managing messages with message endpoints in Liberty

Manage message delivery for message-driven beans (MDB) that are deployed as message endpoints.

About this task

You can use a server command or MBean to manage delivery of a message to your message-driven beans that are acting as listeners on specific endpoints, which are destinations. With a server command or MBean, you can manage the enterprise information system (EIS) resources that your message-driven beans use.

With a server command and MBean, you can activate and deactivate specific endpoints within your applications to ensure that messages are delivered only to listening message-driven beans that are interacting with healthy EIS resources. This capability enables you to optimize the performance of your JMS applications in situations where an EIS resource is not behaving as expected. Message delivery to an endpoint typically fails when the message-driven bean that is listening invokes an operation against a resource that is not healthy. For example, a messaging provider, which is an inbound resource adapter, might fail to deliver messages to an endpoint when its underlying message-driven bean attempts to commit transactions against a database server that is not responding.

Tip: Design your message-driven beans to delegate business processing to other enterprise beans. Do not access the EIS resources directly in the message-driven bean, but do so indirectly through a delegate bean.

The ability to activate and deactivate message endpoints alleviates two problems with applications that provide message endpoints that access resources:

Failed messages require additional processing, such as delivering them to the listening endpoint again or redirecting them to alternate destinations that process failed messages. In addition, a resource adapter might redeliver a message to an endpoint an infinite number of times.
Message redirection requires the implementation of specialized destinations (queues and listeners) to process failed messages, as well as the logic to detect message failures. Message redirection is potentially error prone and computationally expensive due to its complexity.

The ability to deactivate (pause) and reactivate (resume) a specific message endpoint alleviates these problems by enabling an administrator to deactivate the endpoint from processing messages that are destined to fail. When the message endpoint is deactivated, you can repair the resource that is causing the problems and reactivate the endpoint to resume handling message requests. Your troubleshooting does affect the resource adapter or the application that is hosting the endpoint.

You can also use the autoStart attribute in the activation specification to make the message endpoint start out in a deactivated state. When you set this property to false , the message-driven bean does not start receiving messages when the application is started. Use this setting to automatically deactivate a message endpoint when you know that certain tasks must be completed, services must be started, or checks must be carried out, before message handling begins. You activate the message endpoint in the same way as you reactivate a message endpoint that you paused during its operation. The default value for the autoStart attribute is true.

Procedure

Use the server pause and resume commands to control the state of message endpoints.

See Pausing and resuming a Liberty server from the command line.

For z/OS®, also see Pausing and resuming a Liberty server from the z/OS console.
Use the ServerEndpointControlMBean to control the state of message endpoints.

Results

The behavior you observe when you deactivate (pause) a message endpoint depends on various factors, including the resource adapter that manages the message endpoint, the configuration of the message endpoint, and the application server topology. Some specific examples of interest are as follows:

MDB listening on a non-durable topic: The behavior that is implied by the deactivation (pause) of a message endpoint often depends on the function that it is fulfilling. For example, if you configured a message-driven bean to listen on a non-durable topic, deactivating the message endpoint causes the subscription to be closed. The message-driven bean does not receive any messages that are published while the message endpoint is paused.
MDB listening on a durable topic: If you configured a message-driven bean to listen on a durable topic, deactivating the message endpoint causes the subscription to close. Dependent on the configuration, any messages that are published while the message endpoint is paused might be held unconsumed by the messaging engine until the message endpoint is resumed, at which point they are consumed.
MDBs with clustering: If your messaging engine supports clustering it might be possible, dependent on configuration, to enable messages that are destined to the paused message endpoint to be redirected to other message-driven beans.