Any runtime errors in a JMS application are reported by exceptions. The majority of JMS methods throw a JMSException to indicate an error. It is good programming practice to catch these exceptions and display them on a suitable output device.
Each JMS exception encapsulates a message identifier and some associated message text, which describes the error that has occurred. The message identifier has the format MQJMSnnnn, where nnnn is an integer in the range 0000 to 9999. For each message identifier, there is a corresponding field in the MQJMS_Messages class. In the definition of the MQJMS_Messages class, the description of the field contains an explanation of why the error occurred and a suggested user response.
To determine which field in the MQJMS_Messages class corresponds to a given message identifier, you must look in the specification of the WebSphere MQ JMS API that is supplied as HTML pages generated by the Javadoc tool. The MQJMS_Messages section of the Constant Field Values page contains a table that lists each message identifier and its corresponding field in the MQJMS_Messages class.
A JMSException can contain a further exception embedded within it. For JMS, this can be a valuable way to pass important information about the error from the underlying transport. In the case of WebSphere MQ JMS, an MQException is thrown in WebSphere MQ base Java whenever an error occurs in WebSphere MQ, and this exception is usually included as the embedded exception in a JMSException.
The implementation of JMSException does not include the embedded exception in the output of its toString() method. Therefore, you must check explicitly for an embedded exception and print it out, as shown in the following example:
try { . . code that might throw a JMSException . } catch (JMSException je) { System.err.println("caught "+je); Exception e = je.getLinkedException(); if (e != null) { System.err.println("linked exception: "+e); } }
For asynchronous message delivery, the application code cannot catch exceptions raised by failures to receive messages. This is because the application code does not make explicit calls to receive() methods. To cope with this situation, you can register an ExceptionListener, which is an instance of a class that implements the onException() method. When a serious error occurs, this method is called with the JMSException passed as its only parameter. Further details are in Sun's JMS documentation.
The WebSphere MQ JMS implementation uses report messages from the broker to confirm whether registration and de-registration requests have been successful. These report messages are sent to the queue, SYSTEM.JMS.REPORT.QUEUE, on the local queue manager and are normally consumed by the WebSphere MQ JMS. Under some error conditions, however, they might remain on the queue.
WebSphere MQ JMS supplies a Java application, PSReportDump, which dumps the contents of the queue, SYSTEM.JMS.REPORT.QUEUE, in plain text format. The information in the dump can be analyzed by you or by IBM support staff. You can also use the application to delete all the messages in the queue after a problem is diagnosed or fixed.
The compiled form of the application is in the <MQ_JAVA_INSTALL_PATH>/bin directory. To start the application, change to this directory and use the following command:
java -Djava.library.path=library_path PSReportDump [-m queueManager] [-clear]where library_path is the path to the WebSphere MQ Java libraries
(see The WebSphere MQ Java libraries), and:
The output from the application is sent to the screen, or you can redirect it to a file.
If a large number of JMS clients connect directly to a broker running on Windows, and the connections happen almost simultaneously, a java.net.BindException address in use exception might be thrown in response to a request to connect to the broker. You can try to avoid this by catching the exception and retrying, or by pacing the connections.
Notices |
Downloads |
Library |
Support |
Feedback
![]() ![]() |
csqzaw1378 |