Manage message delivery for MDBs deployed as message endpoints
Overview
This section discusses management of message delivery for message-driven beans (MDBs) deployed as message endpoints.
The message endpoints are managed beans (MBeans) for inbound resource adapters compliant with JCA v1.5.
The appserver provides message endpoint MBeans to assist you in managing the delivery of a message to the MDBs acting as listeners on specific endpoints, which are destinations, and in managing the enterprise information system (EIS) resources utilized by these MDBs.
- MDBs deployed as message endpoints are not the same as MDBs configured against a listener port.
- MDBs used as message endpoints must be deployed using an ActivationSpecification defined within a resource adapter configuration for JCA V1.5.
With message endpoint MBeans, we can activate and deactivate specific endpoints within the applications to ensure that messages are delivered only to listening MDBs interacting with healthy EIS resources. This capability allows you to optimize the performance of the 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 not healthy.
For example, a messaging provider, which is an inbound resource adapter that is JCA V1.5 compliant, might fail to deliver messages to an endpoint when its underlying MDB attempts to commit transactions against a database server not responding.
Design the MDBs to delegate business processing to other enterprise beans. Do not access the EIS resources directly in the MDB, 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
- Redirecting them to alternate destinations that process failed messages
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
- 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, you will not affect the resource adapter or the application that is hosting the endpoint.
Procedure
- From the admin console, navigate to the Message Endpoints panel for the application that is hosting the message endpoint.
Applications | Application Types | Websphere enterprise apps | application_name | Runtime panel | Message EndpointsThe panel lists the set of message endpoints hosted by the application.
- Deactivate the message endpoint by selecting the appropriate endpoint and clicking Pause.
- When the message endpoint is inactive, diagnose and repair the underlying cause of the delivery failures.
- Reactivate the message endpoint by selecting the appropriate endpoint and clicking Resume.
Results
The behavior you will observe when you deactivate a message endpoint using the message endpoint MBean is dependent upon a variety of factors, including...
- Resource adapter that manages the message endpoint
- Configuration of the message endpoint
- Appserver topology
Some specific examples...
- MDB listening on a non-durable topic
The behavior that is implied by the deactivation of a message endpoint is often dependent upon the function that it is fulfilling.
For example, if we have configured an MDB 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 that any messages that are published during the time that the message endpoint is paused will not be received by the MDB.
- Clustered MDB
In this scenario an MDB 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 MDB, a non-clustered queue
In this scenario, we have a cluster of servers with the same MDB deployed to them. This is similar to the case, in which we have different MDBs with the same message selection criteria, except that in this case the MDBs are logically the same MDB. Pausing the endpoint will cause only one of the servers to stop receiving messages, and the other MDBs will receive all the messages; none of the messages will be orphaned. To stop all of the endpoints, direct each server in the cluster to stop the local message endpoint.
- Clustered MDB, clustered queue
In this scenario, each MDB is pulling messages from a different partition of the queue. Messaging through WebSphere MQ and the Service Integration Bus have similar, but different, capabilities. If using WebSphere MQ, then pausing one endpoint will not allow the other instances of the MDB to receive the messages. In the Service Integration Bus, messages from a paused endpoint will be redirected to the other MDBs.
Related tasks
Manage the message endpoint lifecycle using scripting