Configuring and Managing the WebLogic Messaging Bridge
![]() |
![]() |
![]() |
![]() |
![]() |
![]() |
The main objective when tuning a messaging bridge is to improve overall messaging performance. Raw speed, though important, is only one of several performance-related factors. Other performance factors include reliability, scalability, manageability, monitoring, user transactions, message-driven bean support, and integration with an application server.
The following sections provide information on various methods to improve message bridge performance:
When the Asynchronous Mode Enabled
attribute is set to false and the quality of service is Exactly-once
,
the Batch Size
attribute can be used to reduce the number of transaction commits by increasing the number of messages per transaction (batch). The best batch size for a bridge instance depends on the combination of JMS providers used, the hardware, operating system, and other factors in the application environment. See Configure transaction properties in Administration Console Online Help.
When the Asynchronous Mode Enabled
attribute is set to false and the quality of service is Exactly-once
,
the BatchInterval
attribute is used to adjust the amount of time the bridge waits for each batch to fill before forwarding batched messages. The best batch interval for a bridge instance depends on the combination of JMS providers used, the hardware, operating system, and other factors in the application environment. For example, if the queue is not very busy, the bridge may frequently stop forwarding in order to wait batches to fill, indicating the need to reduce the value of the BatchInterval
attribute. See Configure transaction properties in Administration Console Online Help.
An Exactly-once
quality of service may perform significantly better or worse than At-most-once
and Duplicate-okay
.
When the Exactly-once
quality of service is used, the bridge must undergo a two-phase commit with both JMS servers in order to ensure the transaction semantics and this operation can be very expensive. However, unlike the other qualities of service, the bridge can batch multiple operations together using Exactly-once
service.
You may need to experiment with this parameter to get the best possible performance. For example, if the queue is not very busy or if non-persistent messages are used, Exactly-once
batching may be of little benefit. See Configure messaging bridge instances in Administration Console Online Help.
If message ordering is not required, consider deploying multiple bridges.
Multiple instances of the bridge may be deployed using the same destinations. When this is done, each instance of the bridge runs in parallel and message throughput may improve. If multiple bridge instances are used, messages will not be forwarded in the same order they had in the source destination. See Create messaging bridge instances in Administration Console Online Help.
Consider the following factors when deciding whether to use multiple bridges:
A general bridge configuration rule is to provide a thread for each bridge instance targeted to a server instance. Use one of the following options to ensure that an adequate number of threads is available for your environment:
weblogic.jms.MessagingBridge
class. See Understanding Work Managers in Designing and Configuring WebLogic Server Environments.Thread Pool Size
property in the Messaging Bridge Configuration section on the Configuration: Services page for a server instance. To avoid competing with the default execute thread pool in the server, messaging bridges share a separate thread pool. This thread pool is used only in synchronous mode (Asynchronou
s Mode Enabled is not set). In asynchronous mode the bridge runs in a thread created by the JMS provider for the source destination. Deprecated in WebLogic Server 9.0.
If the bridge is listening on a topic and it is acceptable that messages are lost when the bridge is not forwarding messages, disable the Durability Enabled
flag to ensure undeliverable messages do not accumulate in the source server's store. Disabling the flag also makes the messages non-persistent. See Configure messaging bridge instances in Administration Console Online Help.
If a messaging bridge source or target is a WebLogic destination, deploy the bridge to the same WebLogic server as the destination. Targeting a messaging bridge with one of its destinations eliminates associated network and serialization overhead. Such overhead can be significant in high-throughput applications, particularly if the messages are non-persistent.
The Asynchronous Mode Enabled
attribute determines whether the messaging bridge receives messages asynchronously using the JMS MessageListener interface
, or whether the bridge receives messages using the synchronous JMS APIs. In most situations, the Asynchronous Enabled
attributes value is dependent on the QOS required for the application environment as shown in Table 5-1:
See Configure messaging bridge instances in Administration Console Online Help.
A quality of service of Exactly-once
has a significant effect on bridge performance. The bridge starts a new transaction for each message and performs a two-phase commit across both JMS servers involved in the transaction. Since the two-phase commit is usually the most expensive part of the bridge transaction, as the number of messages being processed increases, the bridge performance tends to decrease.
Note: In WebLogic Server 9.1, your synchronous consumers can also use the same efficient behavior as asynchronous consumers by enabling the Prefetch Mode for Synchronous Consumers option on JMS connection factories, as described in Receiving Messages Synchronously in Programming WebLogic JMS.
In situations where a quality of service of Exactly-once
is not required, the source destination can pipeline or process multiple messages in each transaction. If an application uses asynchronous consumers (such as MDBs), consider increasing the WebLogic JMS Connection Factory's configured MessagesMaximum
value.
Note: Some non-WebLogic JMS implementations do not pipeline messages, or optimize the asynchronous listeners, in which case the Asynchronous Mode Enabled
parameter may have little effect.
If the asynchronous pipeline size is already set to 1, this may indicate that the application has enabled ordered redelivery, which in turn means that the pipeline must not be increased. See "Ordered Redelivery of Messages" in Programming WebLogic JMS.
WebLogic JMS pipelines messages are delivered to asynchronous consumers, otherwise known as message listeners. This action aids performance because messages are aggregated when they are internally pushed from the server to the client. The messages backlog (the size of the pipeline) between the JMS server and the client is tunable by configuring the MessagesMaximum
setting on the connection factory. See "Asynchronous Message Pipeline" in Programming WebLogic JMS.
In some circumstances, tuning the MessagesMaximum
parameter may improve performance dramatically, such as when the JMS application defers acknowledges or commits. In this case, BEA suggests setting the MessagesMaximum value to:
Tuning the MessagesMaximum
value too high can cause:
MessagesMaximum
has a value of 10,000,000, the first consumer client to connect will get all messages that have already arrived at the destination. This condition leaves other consumers without any messages and creates an unnecessary backlog of messages in the first consumer that may cause the system to run out of memory.
![]() |
![]() |
![]() |