Manage messages with message endpoints

Manage message delivery for message-driven beans (MDB) deployed as message endpoints. The message endpoints are managed beans (MBeans) for inbound resource adapters that are compliant with Java EE Connector Architecture (JCA) Version 1.5.

The application server provides message endpoint MBeans to assist us in managing the delivery of a message to the message-driven beans that are acting as listeners on specific endpoints, which are destinations, and in managing the enterprise information system (EIS) resources that are utilized by these message-driven beans. Message-driven beans deployed as message endpoints are not the same as message-driven beans configured against a listener port. Message-driven beans used as message endpoints must be deployed using an ActivationSpecification that is defined within a resource adapter configuration for JCA Version 1.5.

With message endpoint MBeans, we can activate and deactivate specific endpoints within the applications to ensure that messages are delivered only to listening message-driven beans interacting with healthy EIS resources. This capability allows us to optimize the performance of our 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 that is JCA Version 1.5 compliant, 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.

Design the 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.

Message endpoint MBeans alleviate two problems inherent to 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 capability to deactivate (pause) and reactivate (resume) a specific message endpoint alleviates these problems by enabling the administrator to deactivate the endpoint from processing messages that are destined to fail. When the message endpoint is deactivated, we can repair the resource that is causing the problems and reactivate the endpoint to resume handling message requests. In the course of troubleshooting, we will not affect the resource adapter or the application hosting the endpoint.

If we are connecting to IBM MQ, we can also use the WAS_EndpointInitialState custom property in the activation specification to make the message endpoint start out in a deactivated state. When we set this property to Inactive, the message-driven bean connects with the destination, but does not start receiving messages. 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 we would reactivate a message endpoint that you paused during its operation.

Tasks

1. Use the administrative console, navigate to the Message Endpoints panel for the application hosting the message endpoint.

   1. Select...
      Applications > Application Types > WebSphere enterprise applications > application_name Runtime panel > Message Endpoints

      The panel lists the set of message endpoints that are hosted by the application.

2. Optional: Temporarily disable a message endpoint from handling messages and troubleshoot the problem.
   1. Deactivate the message endpoint by selecting the appropriate endpoint and clicking Pause.
   2. When the message endpoint is inactive, diagnose and repair the underlying cause of the delivery failures.
   3. Reactivate the message endpoint by selecting the appropriate endpoint and clicking Resume.

3. Optional: Activate a message endpoint that started out in a deactivated state. Select the appropriate endpoint and click Resume.

The behavior we will observe when you deactivate (pause) a message endpoint using the message endpoint MBean is dependent upon a variety of 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 (dependent on configuration): The behavior that is implied by the deactivation (pause) of a message endpoint is often dependent upon the function that it is fulfilling. For example, if we have configured a message-driven bean to listen on a non-durable topic on the service integration bus, deactivating the message endpoint is analogous to stopping the application and will cause the subscription to be closed. This means any messages that are published during the time that the message endpoint is paused will not be received by the message-driven bean.

• Clustered message-driven bean (dependent on topology): In this scenario a message-driven bean application has been deployed to a cluster of servers. A given message endpoint MBean controls only the behavior of the MDB in one server from the cluster, so will cause only one server to stop processing messages. Depending upon the messaging configuration and the specific resource adapter in use the messages that would have been consumed by the paused message endpoint may be consumed by the active message endpoints in the cluster, or they may remain unconsumed until the paused message endpoint is resumed.

• Clustered message-driven bean, a non-clustered queue: In this scenario, we have a cluster of servers with the same message-driven bean deployed to them. This is similar to the case, in which we have different message-driven beans with the same message selection criteria, except that in this case the message-driven beans are logically the same message-driven bean. Pausing the endpoint will cause only one of the servers to stop receiving messages, and the other message-driven beans will receive all the messages; none of the messages will be orphaned. To stop all of the endpoints, we must direct each server in the cluster to stop the local message endpoint.

• Clustered message-driven bean, clustered queue: In this scenario, each message-driven bean is pulling messages from a different partition of the queue. Messaging through IBM MQ and the Service Integration Bus have similar, but different, capabilities. If we are using IBM MQ, then pausing one endpoint will not allow the other instances of the message-driven bean to receive the messages. In the Service Integration Bus, messages from a paused endpoint will be redirected to the other message-driven beans.

Subtopics

• Manage message endpoints
  

Manage the message endpoint lifecycle

IBM MQ messaging provider activation specification settings