FAQs: WebLogic Messaging Bridge

 

• Why did the messaging bridge fail to connect to the source bridge destination?

• 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?

• Can I configure the messaging bridge to automatically downgrade the quality of service if the Exactly-once service isn't available on either the source or target bridge destination?

• Why do I get a security authorization exception when attempting to forward messages from a WebLogic Server 6.1 destination to a release 7.0 or later destination?

• When configuring a source or target messaging bridge destination, do I need to set the Adapter Classpath field?

• Can the messaging bridge forward durable subscription messages between separate WebLogic Server 6.1 and release 7.0 or later domains?

• How do I enable debugging for the messaging bridge?

• What do the messaging bridge monitoring states indicate on the Server -> Services ->Monitor -> Messaging Bridge Administration Console page?

• Is there another way to monitor the messaging bridge without using the Administration Console?

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 —> General 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—make sure 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.

Can the messaging bridge handle two-phase or global transactions between separate WebLogic Server domains or between different releases?

Yes, as long as the communication is between source and target WebLogic domains that are both running release 6.1 SP3 or later, and the bridge is configured to use the Exactly-once quality of service.

However, in order for the bridge to communicate with a release 7.0 or later domain, you must establish a trusted relationship across the release 6.1 and 7.0 or later domains, as explained in Why do I get a security authorization exception when attempting to forward messages from a WebLogic Server 6.1 destination to a release 7.0 or later destination?.

For more information about using the Exactly-once QOS when interoperating between release 6.1 or later domains, see "Using the Messaging Bridge To Access Destinations In a Release 6.1 or Later Domain" in the Administration Guide.

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\lib directory. For the Exactly-once QOS, the transaction adapter, jms-xa-adp.rar, must be deployed in the release 6.1 domain where the bridge is running, via the select Deployments —> Applications node on the console.

• This jms-xa-adp.rar adapter must also 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.

• 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. To verify this, the following attributes must be set on 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 release 6.1 or later domains, see "Using the Messaging Bridge To Access Destinations In a Release 6.1 or Later Domain" in the Administration Guide.

Can I configure the messaging bridge to automatically downgrade the quality of service if the Exactly-once service isn't available on either the source or target bridge destination?

Yes, just make sure to select the QOS Degradation Allowed check box on the Messaging Bridge —> Configuration —> General administration console page.

Why do I get a security authorization exception when attempting to forward messages from a WebLogic Server 6.1 destination to a release 7.0 or later destination?

java.lang.SecurityException: Invalid Subject: principals=[system]

In WebLogic Server 6.x, the trust relationship between two WebLogic Server domains was established if the system password was the same in both domains. For WebLogic Server 7.0 or later, a trust relationship is established when the Credential attribute for one domain matches the Credential attribute for another domain. Therefore, if you want a WebLogic Server 6.x domain to interoperate with a release 7.0 or later domain, you need to change the Credential attribute in both domains to the password of the "system" user in the release 6.x domain.

• For more information about establishing a trust relationship between release 6.1 and 7.0 or later domains for the messaging bridge, see "Enabling Security Interoperability for WebLogic Domains" in the Administration Guide.

• For more information about release 6.1 domain interoperability security, see "Using Compatibility Security" in Managing WebLogic Security.

• For more information about WebLogic Server 7.0 domain interoperability security, see "Enabling Trust Between WebLogic Domains" in Managing WebLogic Security.

I deployed the transactional jms-xa-adp.rar resource adapter on the WebLogic 6.1 domain where the message bridge is running, but I still get a "failed to find bridge adapter" message?

You need to 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 "About the Bridge's Resource Adapters" in the Administration Guide.

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 on release 6.1 or later. When connecting to either a source or target destination that is running on release 6.0 or earlier, the Adapter Classpath field must indicate the location of the classes for the earlier WebLogic Server release. When connecting to a third-party JMS provider, the bridge destination must supply the provider's CLASSPATH in the WebLogic Server CLASSPATH.

Can the messaging bridge forward durable subscription messages between separate WebLogic Server 6.1 and release 7.0 or later domains?

Yes, as long as the WebLogic 7.0 domain is using Service Pack 1 or later. To enable durable messages across the messaging bridge using the Administration Console, select the Durability Enabled attribute on the Messaging Bridge —> Configuration —> General tab.

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 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 Server -> Services ->Monitor -> Messaging Bridge Administration Console page?

When monitoring a messaging bridge's state, use the following table to determine a course of action, if necessary.

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	No.
WARN: Stopped by the administrator	No.
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	No.
WARN: Failed to connect to the source	Check all the parameters configured for the source bridge destination. Check if the source server is running and whether the actual destination is active.
Connected to the source	No.
WARN: Failed to connect to the target	Check all the parameters configured for the target bridge destination. Check if the target server is running and whether the actual destination is active.
Connected to the target	No.
Forwarding messages	No.
WARN: Failed to connect and will reconnect later	Check if the source and target bridge destinations are running and healthy.

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 will be named myserver.bridge.mybridge.

For more information about using run-time Mbean management commands, see "WebLogic Server Command-Line Interface Reference" in the Administration Guide. For more information about programming MBean monitoring notifications, see "Monitoring WebLogic Server MBeans" in Programming WebLogic JMX Services.