Collecting Data: Remote Cache for WebSphere Portal
Collecting troubleshooting data for Remote Caching issues with IBM® WebSphere® Portal expedites time to resolution by enabling IBM Support to provide informed problem analysis.
If you have already contacted IBM Support and must collect data to determine the nature of a problem in WebSphere Portal, review the information below for the available methods of data collection. Otherwise, review Collecting Data: Read first for WebSphere Portal.
Collecting Remote Cache specific information
Provide a detailed scenario to recreate the problem, including logs and screen captures, and information stating exactly where the Remote cache failed. You should clear the logs prior to reproducing the problem so that the logs contain data for only one instance.
A. Verify settings
1. First please ensure you have followed all steps to enable caching for your portlets pages and themes following the steps in the Infocenter
2. Check the following information
There are three portal resources that take influence on the page
1. The portlet
2. The page
3. The theme
Verify the following items
A. Verify the page cache options of the public page on which the portlet resides
(If there is a need to change the cache settings, please restart
-> check if the page is cached now. If not, continue
B. ensure that cache settings are defined at the theme
(See the correct section of the Infocenter Page)
-> Check if the page can be cached now. If not, continue
C. Remove the portlet instance from the page.
-> Check if the empty page (only page and theme is rendered) is cacheable. If even the empty page is not cached, please enable traces remote cache by setting the following traceString in accordance with the instructions documented in the topic "Trace Logging" in the WebSphere Portal Information Center:
For further information regarding logging and tracing in the portal, refer to the topic " Logging and Tracing" in the WebSphere Portal Information Center.
If the empty page is cached, continue.
D. If the empty page is cached, but the page that includes the portlet is not cached, then we have to take a look at the portlet.
->Collect the .war file that contains the portlet that is not cacheable
Please verify that portlet caching is enabled and the cache does not get invalidated by changing the portlet mode, processing a portlet action or exceeding the expiration time limit."
3. Please also collect a full xmlaccess export of your system as well as the following file from under the Appserver Directory
resources.xml from the profile/config directory(there will be many occurrences, please include all)
B. Collect and package the diagnostic data
Once tracing is enabled, you delete the existing logs, reproduce the problem, then collect and compress (archive or zip) the new logs and other data.
- Delete all logs in the directory <WP_profile_root>/logs/WebSphere_Portal.
- Reproduce the problem EXACTLY ONCE.
- Archive (compress) the contents of the<WP_profile_root>/logs/WebSphere_Portal directory.
- inside the zip include a full xmlaccess export of your system
- also include all occurrences of file resources.xml from the profile/config directory(there will be many occurrences, please include all)
C. Collecting and submitting logs and configuration data
1. Reproduce the problem.
2. Run the following script from <wp_profile>/PortalServer/bin to collect the data:
Send the files to IBM Support by using the instructions outlined in Exchanging information with IBM Technical Support for problem determination.
Note: When sending in logs for review, include any relevant screenshots, timestamps, userIds, etc. in order to expedite analysis of the issue.
More support for:
Software version: 7.0, 8.0, 8.5
Operating system(s): AIX, HP-UX, IBM i, Linux, Solaris, Windows, z/OS
Software edition: Enable, Express, Extend, Hypervisor Edition, Server
Reference #: 1468824
Modified date: 12 November 2014
Translate this page: