Diagnosing problems when using JMS
This topic contains several approaches for diagnosing JMS issues you may encounter.
Note:
If the correlator log indicates it has connected to JMS but you are not receiving any messages, this is usually due to a missing call to JMS.onApplicationInitialized. This call is required before the correlator will attempt to receive any messages from JMS.
Consider contacting the vendor of the JMS provider that is being used. JMS brokers are complex pieces of software with many configuration options. JMS providers often maintain on-line databases of known bugs and issues. Software AG is not in a position to provide detailed support or performance tuning for JMS brokers provided by a third party, but the provider may be able to suggest useful changes to configuration options that can affect performance and reliability trade-offs and provide further assistance tracking down crashes, hangs, performance, disconnection and flow control problems.
Check the correlator log file for
WARN and
ERROR messages that may indicate the underlying problem. Also check for any log lines "
Longest delay between a JMS message being sent and the broker delivering it to this receiver is now ", especially after an unexpected disconnection or when testing a correlator/broker machine or network failure. This will give an indication of how your broker redelivers in-doubt messages, and may affect the size of the duplicate detection time-based expiry window.
Check the JMS broker's log files and console for error messages or warnings.
Consider temporarily using
logJMSMessages and
logProductMessages to display all messages being sent and received. This is particularly useful for problems related to mapping; on the other hand it is not useful for diagnosing performance-related issues.
Use the "
JMS Status:" lines to understand what is going on in more detail. Consider setting
logDetailedStatus=true to get more in-depth per-sender and per-receiver status lines.
Check for any log lines "
Longest delay between a JMS message being sent and the broker delivering it to this receiver is now " which may indicate that the broker is behaving strangely or that queued messages from a previous test run are unexpectedly being received, perhaps causing mapping failures or performance problems.
If further assistance from Software AG is required to track down a problem, it is essential to provide a copy of the full correlator log file and the JMS configuration being used to ensure that all the required information is available.
To capture the correlator log output, edit the launch configuration as follows:
1. Right-click the project and select Run As > Run Configurations from the context menu.
2. Ensure the configuration for this project is selected.
3. Select the Components tab.
4. Edit the DefaultCorrelator setting by adding extra command line arguments:
--logfile logs/correlator.log
5. Optionally add --truncate to clear the log file at start up to eliminate confusion with output from previous runs.
Note, simply copying lines from the Console view is usually not adequate for support purposes (for example, status lines are missing and in some cases header information is missing as well).
To collect the essential JMS configuration files:
1. Right-click the project and select Properties from the context menu.
2. In the Resource section, note the directory information listed in the Location field. (Copy the information if desired.)
3. In the file system, navigate to that directory. (Paste the directory information into the Run command of the Windows Start menu.)
4. Zip up the contents of the bundle_instance_files\Correlator-Integrated_JMS sub-directory.
If you are using JNDI to get the connection factory, it is usually necessary to first add and configure a JNDI name for the connection factory you wish to use using the administration tools provided by the JMS implementation you are using. For example, if using Universal Messaging, this would be the Enterprise Manager tool. A common mistake when configuring the JNDI connection factory binding is to use localhost rather than a fully qualified host name or IP address. For many JMS implementations, this will not permit connections from hosts other than the one that the server is running on.