Investigating JMS Problems

Duration: 50 minutes Skills Learned

At the end of this practice, you should be able to:

• Analyze JMS producer and consumer problems

• Monitor JMS communication by using WLST, logs, and debug flags

• Configure delivery failure settings

• Respond to failed messages Overview

In this practice, you monitor and troubleshoot the MedRec JMS infrastructure, which is used to relay notifications about changes in patient data. Typical JMS issues include insufficient quota, expired messages, and duplicate messages.

These troubleshooting scenarios involve both administrative and application issues. You use a combination of the server logs, JMS logs, and WLST. You also use this opportunity to tune WebLogic’s delivery failure features. The system under investigation is shown in the following diagram:

Instructions

1. Set up the practice.

a. Locate a Lab Framework prompt or start a new one. Change directories to

<CURRENT_LAB>.

b. Execute the following:

ant setup_exercise

The Lab Framework introduces some configuration problems in the MedRec JMS resources.

c. Launch the admin console.

d. Locate and inspect the MedRecJMSServer JMS server.

e. Click the Monitoring > Active Destinations tab.

f. This practice concentrates on the JMS queue named PatientNotificationQueue.

Confirm that the Messages Received count is 0.

g. Locate and inspect the MedRec-jms JMS module. Select PatientNotificationQueue.

h. Click the Monitoring tab. Confirm that the Consumers Current column is 0.

Tip: The Messages Total column is the equivalent of Messages Received.

Oracle University and Sentra inversiones y servicios LTDA use only

2. Observe a JMS producer error.

a. From your Lab Framework prompt, navigate to

<CURRENT_LAB>/resources/client.

Tip: The Lab Framework prompt has the correct environment to run the supplied JMS clients. Do not use a standard Linux terminal.

b. Execute this command:

export CLASSPATH=.:$CLASSPATH

Why? The client script needs the current folder to be in the classpath.

c. Execute the runconsumer1.sh script.

d. Monitor PatientNotificationQueue again and verify that the Consumers Current column is now 1.

e. Launch a second Lab Framework prompt, add the current folder to the classpath as before, and execute runproducers1.sh.

This script simulates multiple systems that produce messages simultaneously.

f. Verify that the consumer client is receiving messages via the JMS queue:

Message Received: (TextMessage[ID:<...>, Patient=73, ...]) Tip: The consumer client displays the ID of each message along with its payload text.

g. Verify that the producer application generated one or more errors while sending messages. For example:

Sender 'PatientNotifier3' encountered a problem.

weblogic.jms.common.ResourceAllocationException:

weblogic.messaging.kernel.QuotaException: Quota MedRecJMSServer.Quota.1259940548078 exceeded: ...

Can you guess what the cause of this error is?

3. Configure JMS quotas.

a. Return to the console and Lock it.

b. First, verify the quota resources for the PatientNotificationQueue destination in the JMS module:

1) Click the Configuration > Thresholds and Quotas tab.

2) Confirm that this destination is not currently assigned a quota resource:

c. Now edit MedRecJMSServer.

1) Click the Configuration > Thresholds and Quotas tab.

2) Increase the Messages Maximum field to 100.

3) Save and Activate your changes.

4. Monitor JMS traffic by using WLST.

a. Inspect the contents of the

<CURRENT_LAB>/resources/wlst/monitorJMS1.py file.

b. Launch a third Lab Framework prompt.

c. Execute the monitorJMS1.py WLST script.

Oracle University and Sentra inversiones y servicios LTDA use only

d. Note the current number of messages on MedRecJMSServer (0). Leave the script running.

e. Execute runproducers1.sh again. While the producer clients are running, monitor the WLST output. Wait some time after the producer clients finish and both the number of current and pending messages should decrease to 0.

f. Verify that the producer now generates no errors and that all messages are received by the consumer.

g. Kill the WLST script.

5. Observe a scenario with missing messages.

a. Confirm that the consumer client is still running.

Tip: You may wish to stop and restart the consumer client between tests to help distinguish the messages for each test.

b. Execute the <CURRENT_LAB>/resources/client/runproducers2.sh script.

c. Compare the output from the producer script to the output from the consumer script.

Notice that the consumer is not receiving the same number of messages that were sent (15).

d. Return to the console and monitor PatientNotificationQueue. Confirm that there are currently no messages on the destination.

6. Configure delivery failure settings.

a. Lock the console.

b. Edit the MedRec-jms JMS module.

c. Under Summary of Resources, click New.

d. Select the Queue option and click Next.

e. Enter the following values:

Field Value

Name ErrorQueue

JNDI Name com.bea.medrec.jms.ErrorQueue Click Next.

f. For Subdeployments, select DeployToMedRecJMSServer. Click Finish.

g. Edit PatientNotificationQueue.

h. Click the Configuration > Delivery Failure tab.

i. Update the following fields:

Field Value

Expiration Policy Redirect Error Destination ErrorQueue

Click Save.

7. Analyze message events by using JMS logs.

a. Click the Configuration > Logging tab.

b. Select the following check boxes:

Enable Message Logging All Properties

Oracle University and Sentra inversiones y servicios LTDA use only

c. Save and Activate your changes.

d. Run the <CURRENT_LAB>/resources/wlst/monitorJMS2.py WLST script.

e. Repeat the previous test (runproducers2.sh and runconsumer1.sh).

f. Monitor the WLST script output. Verify that some messages are failing and are being moved to the ErrorQueue destination. For example:

PatientNotificationQueue ErrorQueue

TOTAL CURRENT PENDING TOTAL CURRENT PENDING