Default Messaging Provider Problem Determination - IBM Redbooks

More documents

Recommendations

Info

Collect the data For a complete list of messaging message prefixes, see: http://publib.boulder.ibm.com/infocenter/wasinfo/v6r0/topic/com.ibm.websphe re.nd.doc/info/ae/ae/welc_ref_trb_msg.html You can find explanations of individual messages in the WebSphere Information Center. When searching for message prefixes, enclose the prefix in double quotation marks. ► What changes have been made to the application, configuration, WebSphere Application Server maintenance level, operating system, network, or hardware? ► What are the implications of backing out any changes that were made to verify whether that the change precipitated the problem? ► Do the basic functions of the application work, or is this some new scenario (for example, some code that has been added or a newly tested function)? ► Have you tested the IVT applications and the samples to ensure that they work OK? This is extremely important, because it establishes the basic functionality of the application server. ► Have you validated the WebSphere Application Server configuration using $AdminConfig validate? Although this is not infallible, it does provide a check of the configuration changes that you might have made. Configuration problems can also be viewed from the administrative console (Troubleshooting → Configuration Problems). ► Has there been a change to the data being used? A commonly encountered problem is where a new data format (long messages, object messages, or null data) is used for the first time and this precipitates an error in the processing of that data. Having established the type of change that might have precipitated the problem, it might be expedient to back out the change to allow the system to continue running. There is a minimum set of documentation that is required for investigating any problem. This information should be gathered before starting to examine any messaging problems. Then, depending on the type and the complexity of the problem, additional documentation might be required. For our initial investigations, the minimum set of documentation that you should gather is: ► SystemOut.log ► SystemErr.log ► Exception logs in FFDC directory ► Exceptions received by any client applications 6 WebSphere Application Server V6: Default Messaging Provider Problem Determination
You can find information about finding and reviewing logs and traces in WebSphere Application Server V6: Diagnostic Data, REDP-4085, at: http://www.redbooks.ibm.com/redpapers/pdfs/redp4085.pdf If the problem is difficult to recreate or disruptive to business operations, see “The next step” on page 50 for a complete list of documentation to collect before continuing. In particular, you should review the MustGather document for service integration technologies for a complete list of documentation that is required by IBM support. Analyze the high-level symptoms At this point, the problem could be any of the categories that we have discussed. The following analysis strategy should help you define the problem. Begin by examining the documentation that you have gathered. Look for any error codes, exception codes, or stack traces. Use these as search arguments in the appropriate IBM support sites and the WebSphere Information Center. It is also a useful technique to use an Internet search engine to search the IBM Web site for matching symptoms and message codes: http://www.ibm.com/software/webservers/appserv/was/support/ Often, the explanatory notes in the WebSphere Information Center will be sufficient to resolve a problem. Ensure that the messaging engine has started The first step in diagnosing any messaging problem is to ensure that all the messaging engines on the bus are active. To check the status of the messaging engines from the administrative console: 1. Select Service integration → Buses. 2. Click the bus name to open the details page. 3. Click Bus members. 4. Click the bus member. This shows a list of messaging engines and their status, as shown in Figure 2 on page 8. WebSphere Application Server V6: Default Messaging Provider Problem Determination 7
Page 1 and 2: Redbooks Paper WebSphere Applicatio
Page 3 and 4: DB Messaging data store WebSphere A
Page 5: Problem categories Work the problem
Page 9 and 10: Figure 3 Viewing messages on the qu
Page 11 and 12: Note: In the following examples, th
Page 13 and 14: embedded exception code, CWSIS1524E
Page 15 and 16: : Caused by: java.sql.SQLException:
Page 17 and 18: Tip: Defining the data source for t
Page 19 and 20: Immediately after attempting to tak
Page 21 and 22: : [7/8/05 10:49:26:631 EDT] 0000002
Page 23 and 24: Finally, you must ensure that you d
Page 25 and 26: Message Consumer WebSphere Applicat
Page 27 and 28: Symptom: Messages disappear when us
Page 29 and 30: However, a message code is seen in
Page 31 and 32: CWSIS1538I, which indicate that the
Page 33 and 34: [...] 00000037 SibMessage I [NewBus
Page 35 and 36: Figure 13 Queue destination propert
Page 37 and 38: Figure 14 Exception destination is
Page 39 and 40: Figure 15 Mediation Destination 1 D
Page 41 and 42: Figure 17 Map module to server 5. E
Page 43 and 44: Figure 18 Messages waiting for medi
Page 45 and 46: To connect correctly to the bus, th
Page 47 and 48: the network environment and worksta
Page 49 and 50: Product errors If the messaging eng
Page 51 and 52: have gathered for errors related to
Page 53 and 54: Notices This information was develo

Default Messaging Provider Problem Determination - IBM Redbooks

Create successful ePaper yourself

Delete template?

Save as template?