5 FAQs: WebLogic Messaging Bridge
This chapter includes the following sections:
Why did the messaging bridge fail to connect to the source bridge destination?
Either an error occurred when configuring the source bridge destination parameters, or the actual source destination is not running and cannot communicate with the messaging bridge.
-
Verify whether the bridge's source destination is correctly configured, by making sure that the following fields on the JMS Bridge Destination Æ Configuration console page have been properly completed:
-
Connection URL—this must be the URL of the JNDI provider used to look up the connection factory and actual destination.
-
Destination JNDI Name—this must be the JNDI name of the actual destination mapped to the source bridge destination.
-
Connection Factory JNDI Name—this must be the connection factory used to create a connection for the actual destination mapped to the source bridge destination.
-
User Name/Password—ensure that this user ID has permission to access the actual source destination.
-
-
Verify that the actual source queue or topic destination mapped to the source bridge destination is running and healthy, as follows:
-
Is the WebLogic Server instance hosting the source destination running?
-
Is the JMS server hosting the source destination correctly deployed?
Note:
This troubleshooting scenario for correcting a source bridge destination connection failure also applies to target bridge destinations.
-
Why are some of my messages not being forwarded?
Normally, a messaging bridge should forward all messages. If some messages are not being forwarded, here are some possible reasons:
-
Some messages may have an expiration time, in which case either the JMS provider for the source or target destination expires the message.
-
If you configured the bridge source destination to specify a selector filter, only the filtered messages are forwarded.
-
A bridge does not directly provide an option to automatically move messages to an error destination, or to automatically delete messages, after a limited number of forward attempts. However, a JMS provider may provide such an option, which could, in turn, effect any messages on the bridge source destination. If a redelivery limit option is enabled on the JMS provider that hosts the bridge source destination, consider reconfiguring the provider to prevent the bridge automatic retry mechanism from causing messages to exceed the redelivery limit.
Can the messaging bridge handle two-phase or global transactions between separate WebLogic Server domains or between different releases?
I configured the messaging bridge to use the Exactly-once quality of service for two-phase transactions. So why am I getting a "quality of service is unreachable" error?
There are some additional configuration requirements for the messaging bridge to handle transactions between WebLogic domains:
-
The supported adapters are located in the
WL_HOME
\server\lib
directory. For theExactly-once
QOS, the transaction adapter,jms-xa-adp.rar
, must be deployed in the domain where the bridge is running, through the select Deployments > Connector node on the console. -
This
jms-xa-adp.rar
adapter must also be identified in the Adapter JNDI Name attribute aseis.jms.WLSConnectionFactoryJNDIXA
on the JMS Bridge Destination > Configuration tab for both the source and target bridge destinations. -
For WebLogic JMS, verify that you are using the transactional
XAConnectionFactory
for the queue or topic destinations mapped to both the source and target bridge destinations. Verify by reviewing the JMS > Connection Factory > Configuration > Transactions console tab or in the configuration file (config.xml
):UserTransactionsEnabled=true XAConnectionFactory=true
-
For third-party JMS vendors, verify that you are using a transactional connection factory for the destinations mapped to the source and target bridge destinations.
For more information about using the Exactly-once QOS when interoperating between releases, see Interoperating with Different WebLogic Server Releases.
Can a messaging bridge to automatically downgrade the quality of service if the Exactly-once service is not available on either the source or target bridge destination?
Yes, just ensure to select the QOS Degradation Allowed
check box on the Messaging Bridge > Configuration > General WebLogic Server Administration Console page.
I deployed the transactional jms-xa-adp.rar resource adapter on domain where the message bridge is running, but I still get a "failed to find bridge adapter" message?
Associate both the source and target bridge destinations with the appropriate .rar
adapters in order for the bridge to communicate with them. For the jms-xa-adp.rar
transaction adapter, it must be identified in the Adapter JNDI Name attribute as eis.jms.WLSConnectionFactoryJNDIXA
on the JMS Bridge Destination Æ Configuration tab for both the source and target bridge destinations.
Note:
The "failed to find bridge adapter" message does not necessarily indicate a problem if it only occurs once. However, if it occurs repeatedly, you should check the adapter deployment and the adapter JNDI name used in the source and target bridge destinations.
For more information about the bridge resource adapters, see Resource Adapters.
When configuring a source or target messaging bridge destination, do I need to set the Adapter Classpath field?
Leave the Adapter Classpath field blank when connecting to source and target destinations that are both running in WebLogic Server instances. When connecting to a third-party JMS provider, the bridge destination must supply the provider's CLASSPATH
in the WebLogic Server CLASSPATH
.
How do I enable debugging for the messaging bridge?
You can enable debugging for the messaging bridge using either of the followings methods:
-
Add the following lines to your WebLogic start script (before the
weblogic.Server
line):-Dweblogic.debug.DebugMessagingBridgeStartup=true -Dweblogic.debug.DebugMessagingBridgeRuntime=true
-
Add the following statements to the ServerDebug entry in your configuration file (
config.xml
) for the server that the messaging bridge is running on:DebugMessagingBridgeStartup="true" DebugMessagingBridgeRuntime="true"
Once debugging is enabled for the messaging bridge, the debugging messages are sent to the server log by default. However, if you want them to appear in the WebLogic Server Administration Console, add "DumpToConsole
" to the statements show above. For example:
-Dweblogic.debug.DebugMessagingBridgeStartupDumpToConsole=true
What do the messaging bridge monitoring states indicate on the Monitor Messaging Bridge console page?
When monitoring a messaging bridge's state, use Table 5-1 to determine a course of action, if necessary. For more information, see Manage a Messaging Bridge Instance.
Table 5-1 Messaging Bridge Monitoring States
Description | Action |
---|---|
WARN: Failed to find the source adapter |
Check if the adapter is deployed or the JNDI name in the source JMSBridgeDestination instance is correct. |
WARN: Failed to find the target adapter |
Check if the adapter is deployed or the JNDI name in the target JMSBridgeDestination instance is correct. |
Found both of the adapters and making connections |
NA |
WARN: Stopped by the administrator |
NA |
WARN: Failed to look up the source adapter |
Check if the adapter is deployed or the JNDI name in the source JMSBridgeDestination instance is correct. |
WARN: Failed to look up the target adapter |
Check if the adapter is deployed or the JNDI name in the target JMSBridgeDestination instance is correct. |
Found two adapters and about to make connections |
NA |
WARN: Failed to connect to the source |
|
Connected to the source |
NA |
WARN: Failed to connect to the target |
|
Connected to the target |
NA |
Forwarding messages |
NA |
WARN: Failed to connect and will reconnect later |
Check if the source and target bridge destinations are running and healthy. |
Can the messaging bridge use distributed destinations as source and target destinations?
Yes, the messaging bridge can send to and receive from distributed destinations. Oracle recommends the following configurations:
-
If the source is distributed destination, the bridge is pinned to one of the members when it connects to the destination. It stays connected only to that member until it reconnects. The bridge does not receive messages from the other members of the distributed destination. Therefore, the best practice is to configure one bridge for each member of a distributed destinations using the member's
JNDIName
. -
If the target is a distributed destination, the best practice is to send to the distributed destination using the distributed destination's
JNDIName
and disable server affinity. This allows the distributed destination to load balance incoming messages.
Is there another way to monitor the messaging bridge without using the Administration Console?
Yes, there is a run-time MBean (MessagingBridgeRuntimeMBean
) for each bridge instance. WebLogic Server run-time MBeans provide a snapshot of information about domain resources. When a particular resource in the domain (such as a messaging bridge) is instantiated, an MBean instance is created which collects information about that resource.
The MessagingBridgeRuntimeMBean
has a getState()
method that currently returns a String
("Active" or "Inactive") and a getDescription()
method, which returns a String
with more detailed information. The name of a bridge runtime MBean consists of the WebLogic Server instance name and the bridge name. If a bridge named mybridge, runs on WebLogic Server instance named myserver, the bridge runtime MBean is named myserver.bridge.mybridge.
For more information, see:
-
Introduction and Roadmap in Developing Custom Management Utilities Using JMX for Oracle WebLogic Server .
-
Using the WebLogic Scripting Tool in Understanding the WebLogic Scripting Tool .
Can I use the Message Bridge in a Mixed or Dynamic Cluster?
Yes, a bridge can be targeted to any type of cluster. See the next FAQ entry for more information about tuning a bridge that is cluster-targeted.
What are the recommendations for the bridge Distribution Policy and Migration Policy settings?
The bridge Distribution Policy and Migration Policy settings take effect when a bridge is cluster-targeted. A bridge is cluster-targeted when its target is directly set to a cluster, or when a bridge is scoped to a resource group and the resource group is in turn targeted to a cluster.
When an instance per server is desired for a cluster-targeted bridge, Oracle recommends setting the bridge Distributed Policy and Migration Policy to Distributed/Off respectively - these are the defaults.
When a single instance per cluster is desired for a cluster-targeted bridge, Oracle recommends setting the bridge Distributed Policy and Migration Policy to Singleton/On-Failure respectively. Singleton/On-Failure bridges will not start unless cluster leasing is also configured. (If you cannot cluster-target a bridge and still need singleton behavior in a configured cluster, you can target the bridge to a ‘Migratable Target’ and configure the Migration Policy on the migratable target to ‘Exactly-Once'.)
Note:
Oracle recommends against setting a bridge Distributed Policy and Migration Policy to Distributed/On-Failure or Distributed/Always.Restart-In-Place settings are ignored for a bridge, since a bridge has its own built-in retry logic.