Troubleshoot WebSphere Portal administration

 

+
Search Tips   |   Advanced Search

 

  1. Troubleshooting issues related to using the portal

  2. Troubleshooting issues related to national language support

  3. Troubleshooting issues related to administering the portal

 

Troubleshooting issues related to using the portal

This section describes problem that can occur when using or administering the portal.

 

Problem: No pages display in the portal (Unix installations with DB2)

If you selected the option to deploy the base portlets (the administration and customization portlets used by the portal) during the portal installation, but no pages are displayed when you open the portal and the following error messages are in the installation log files for the database, there is a shared memory problem with DB2 and the WebSphere Application Server datasources: 

com.ibm.wps.util.DataBackendException: Error during database access!

Nested Exception is com.ibm.websphere.ce.cm.StaleConnectionException:
[IBM][CLI Driver] SQL1224N A database agent could not be started to service a request,
or was terminated as a result of a database system shutdown or a force command.
SQLSTATE=55032

Solution: On Unix installations, you cannot use the WebSphere Portal database directly. Instead, define a local alias for the database. The alias connects to the WebSphere Portal database using a TCP/IP connection. For instructions, see the WebSphere Portal Information Center. Search for the instructions for configuring DB2.

 

Problem: Browser switches to another session when multiple users are logged in from the same client

If a user, such as the portal administrator, logs in to the portal, leaves that login active, and then logs in from another instance of the same browser but using a different user ID, the second instance of the browser might switch to the first user's session and other problems might occur.

Solution: To log in as different users on the same client, use one of the following methods to avoid this problem:

  • If you do not need to maintain session data for any of the user logins, log off from one user account before you log in to the other user account.
  • To maintain active sessions for each user, use a different browser type for each user session. For example, use Netscape Navigator for one login and Microsoft Internet Explorer for the second login.

 

Problem: When modifying user information via WebSphere Portal, unexpected results could occur

When modifying user information via WebSphere Portal, if you receive the error "Backend storage system failed. Please try again later." or the user attributes are not updated in LDAP, it might mean that the default tuning parameters for use with DB2 and IBM Tivoli Directory Server need to be adjusted.

Solution: The default DB2 parameters are: 

APP_CTL_HEAP_SZ 128
APPLHEAP_SZ 128

The parameters above are too small for IBM Tivoli Directory Server and WebSphere Portal on AIX with 2000 user entries.

The HEAP size of UDB is required when updating or inserting data. WebSphere Portal spawns heavy transactions to the LDAP server in any phase, especially changing user attributes, which spawns several updates and inserts. To prevent this problem, the following WebSphere Portal tuning is required: 

su -ldapdb2
db2 -c update db cfg for ldap using APP_CTL_HEAP_SZ 1024
db2 -c update db cfg for ldap using APPLHEAP_SZ 1024

 

Problem: Application error for Edit Layout and Content

An application error might occur when you use the Edit Page task. The sequence of events that result in the problem are:

  1. A new user signs up or enrolls for the portal.
  2. The user logs in.
  3. The user selects the page to work with.
  4. The user selects the Edit Page.
  5. The user selects a portlet on the page and then clicks the edit portlet icon. The edit portlet dialog is displayed in a separate window.
  6. The user edits the portlet and then clicks the OK button. The edit portlet window closes.
  7. The user clicks the edit portlet icon a second time. This time, the edit portlet dialog displays in a separate window, but with the message There has been an application error.

Solution: If this problem occurs, the user should log off and then log in again. Then the problem will not occur again.

 

Problem: A portlet does not appear in your portal

Solution: Ensure that:

  • You are authorized to access the portlet.
  • The portlet has been added to a page in your portal.
  • You are viewing the page that contains the portlet.
  • The device on which you are viewing the portal supports the markup language that the portlet produces.

 

Problem: Portlet contents are blank

When a portlet Web application is unavailable, for example because it was stopped in the appserver, the corresponding portlets will not show an error message but just display no content. In this case, the log file will show one of the following error messages:

  • PEPC0001E: ServletContext belonging to servlet XX could not be found.
  • PEPC0003E: ServletContext lookup for XX returned the portal's context. It has to be a different one.

Solution: Make sure the enterprise application is started by using the appserver's administrative console.

 

Problem: A portlet is not accessible after its portlet application has been updated

Solution: When a portlet application is updated, the updated portlet or portlets might be temporarily inaccessible. If this happens, log out and log back in to the portal again.

 

Problem: An error message after an LTPA timeout that follows a session timeout

After an LTPA timeout following a session timeout, an IllegalArgException error might be displayed and a new login is required.

Solution: Refresh the Web browser by doing one of the following:

  • For Netscape users, press and hold the Shift key and click Reload
  • For Internet Explorer users, press and hold the Shift key and click Refresh.

 

Problem: User or user group search can time out or return too many results

When performing a search that can return a large number of users or user groups, the search might time out or return more results than the system can handle.

Solution: Searches can be set to automatically return a specific number of maximum results or time out after a specified time. See Manage users and groups for details about setting this configuration.

 

Problem: Browser refresh forces a portlet transaction

For portlets that use String-based actions, refreshing the browser could cause the portlet to re-execute its action, creating a problem in some transactional portlets. For example, a user clicking refresh could inadvertently trigger an action that updates the quantity of an item in a shopping cart.

Solution: Modify the portlet by adding the following configuration parameter and value: 

com.ibm.wps.portlet.action.redirect = true

This allows the page and portlet to be reloaded without the action parameters in the URL. You can add and set configuration parameters by clicking Administration, Portlets, then Manage Portlets. Select the portlet to be modified and click Modify parameters.

 

Problem: Receiving session timeout screen

When a user from another appserver instance within the single signon domain of WebSphere Portal with a Session cookie that has the name JSESSIONID and a cookie path that matches the portal URL (for example, the default value /) accesses the WebSphere Portal protected area (for example, myportal), the user will see the session timeout screen. This is because WebSphere Portal cannot distinguish if the cookie sent by the browser was created by itself or by another appserver instance.

Solution: To prevent this problem, the cookie path has to be adjusted so that it can be distinguished from the WebSphere Portal URL in the other Application Server instances that share the same single signon domain. Use the Session Management settings in WebSphere Application Server Administration to specify a unique cookie path for the JSESSIONID cookie.

If you specify the cookie path using "overwrite" option in the session management administration screen at a level other then the web container level, you will have to again specify distributed session settings at that level eventhough they might already be defined at the web container level.

 

Problem: Logging in as two users with a Mozilla browser continues to show one user

Mozilla browsers that come from the same IP address share a common WebSphere Portal session. If a user logs in with two different user IDs at the same time, the browser continues to use the same user, and there is no indication which user is actually logged in to WebSphere Portal. For example, if a user logs in as UserA in one browser window and UserB in another browser window, both windows are UserB, and all content and settings displayed belong to UserB.

Solution: If you want to login as a different user with a Mozilla browser, close all browser instances before logging in as the alternate user.

 

Problem: Parallel portlet rendering does not work when Work Manager is not found

If a Work Manager is not created during the portal installation, the portal gives the following message:

  PEEX0100E Unable to find workload manager wm/wpsWorkmanager

This error message indicates that the Work Manager was not created during portal installation. This can have the following reasons:

  • PME (Programming Model Extensions) was not installed.
  • The asynchronous beans were not selected for the PME installation.

As a result, parallel portlet rendering (PPR) does not work. The PPR component logs the error message PEEX0100E as given above. This message also means that the initialization of the parallel rendering process failed. In the case of this error parallel portlet rendering is turned off automatically. However the portal continues to operate properly without this component. All portlets are rendered sequentially.

Solution: Make sure that the prerequisites to run the PPR component successfully are installed before the installation of the portal. These are as follows:

  1. The appserver is installed including PME.
  2. PME includes the Asynchronous Beans required to create a Work Manager.
  3. A Work Manager named wm/wpsWorkmanager was created during the portal installation.

 

Problem: Document Search portlet fails on anonymous page

If you put the Document Search portlet on an anonymous page so that users can use it without having to log in to the portal, the portlet does not work.

Solution: You need to enable public sessions for your portal. The reason is that the document search portlet needs a valid session for its run time, and by default, sessions are not enabled on anonymous pages in the portal. By default, sessions are only created when a user authenticates and logs in to the portal server.

To enable public sessions, edit the file wp_root/shared/app/config/services/NavigatorService.properties and set the public.session parameter to true. Restart both WebSphere Application Server and WebSphere Portal for your changes to take effect.

 

Problem: Search portlets do not work after reconfiguring from local to remote service or vice versa

If you change the configuration of the search related portlets from local search service to remote search service or vice versa, the portlet does not work. This applies to both the administrative portlet Manage Collections and the end user portlet Document Search.

Cause: You can configure and use the embedded search component in two ways, either accessing a locally installed search service or using a remote search service through the SOAP (Web services) interface. Once you have configured one of the search portlets for access local search service or remote search service, you cannot change its configuration to the other type of service. If you try to do this, the portlet does not work any more.

Solution: If you want to switch to the other type of service (for example, from local to remote), do so manually. Create another copy of the portlet and configure it for the required service type. To configure for local access, leave the SOAP URL parameter empty and to configure for remote access, specify a SOAP URL.

 

Troubleshooting issues related to national language support

This section describes problems that can occur when viewing different languages with WebSphere Portal.

 

Problem: Issues with Netscape AIX set to Turkish

If you access the portal using a Netscape browser running on an AIX client where the locale and the key layout are set to Turkish, some Turkish characters might not display correctly and log in might fail because Netscape on AIX is provided on a limited warranty basis.

Solution: If problems are encountered, it is recommended that an alternate browser or a browser on a different operating system be used to connect to the portal.

 

Problem: Issues with browsers displaying DBCS characters in different locales

When your browser is set to one of the zh_CN, zh_TW, ja_JP or ko_KR locales, you might not be able to view text created in the other three languages.

Solution: To resolve this problem, proceed by the following steps:

  1. Log in to the portal.
  2. Select Administration > Portal Settings > Supported Markups.
  3. Select HTML.
  4. Click on Edit Selected Markup.
  5. Click on Set locale-specific setting.
  6. Select the language as required.
  7. Click on Edit setting for selected language.
  8. Insert UTF-8 in the Character Set entry field.
  9. Confirm all the settings by clicking OK several times until you return to the main panel of the Manage Markups portlet.

 

Problem: Issues with browsers displaying DBCS characters in selection boxes

This information concerns languages that use double-byte character sets (DBCS). Sometimes when DBCS text is displayed in selection boxes (such as the selector for pages), all of the characters are displayed as square boxes. It has not been possible to determine the browser versions and operating systems on which this situation occurs consistently.

Solution: None at this time.

 

Problem: Issues with Information Center and Portal Help search

If you use Microsoft Internet Explorer 6.x to display the WebSphere Portal Information Center or Portal Help and then use the Search function, some corrupted characters might be displayed in the search results list.

Solution: See the Requirements section in the Information Center to view a list of other Web browsers that you can use.

 

Problem: Issues with Microsoft Internet Explorer in a Japanese environment

Solution:

  • If you access the portal in a Japanese environment with Microsoft Internet Explorer, the backslash might be displayed when pushing the Japanese Yen key in an input field of the portal. This is caused by Microsoft Internet Explorer in UTF-8 encoding. To avoid this problem, use other browsers such as Netscape or Mozilla, or change the character set of the portal from UTF-8 to Shift_JIS. Refer to Change the character set for a language.
  • The Rich Text Component of WebSphere Portal Productivity Components allows you to change a normal format to a heading format, and vice versa. This might be not available if you access the portal in a Japanese environment with Microsoft Internet Explorer. To avoid this problem, use other browsers such as Mozilla.

 

Troubleshooting issues related to administering the portal

 

Problem: Cannot use the XML configuration interface if it is externalized in security

If the virtual resource XML_ACCESS that represents access to the XML configuration interface is put under protection of an external security manager, you can no longer use the XML configuration interface.

Solution: If the access rights of WebSphere Portal are externalized to an external security manager, such as Tivoli Access Manager, verify the XML configuration interface virtual resource is not externalized.

 

Problem: Link to launch Edit mode of a portlet disappears

When you use the Edit Layout portlet to edit a page, the page is deactivated and the link to launch the Edit mode of a portlet on that page disappears.

Cause: A page is deactivated immediately after you perform an action in the Edit Content and Layout portlet, for example, Add Portlets or Move Portlets/container.

Solution: Once the page is deactivated after you an action, click Done to leave the page. This activates the page again. When you click the Edit Page link, the Edit Portlet link is displayed.

 

Problem: Administrative Console not loading

WebSphere Portal installs the WebSphere Application Server Administrative Console application into the WebSphere Portal appserver so that it can be used to administer the appserver without requiring another application server instance (by default, server1) to be configured or operational. The default port used for communication is 9081.

Solution: On Windows 2000, a Start Menu item is created to invoke the Administrative Console. If this menu item fails to load the console because of a HTTP 404 error that means that the Application Server is assigned a different administration port than was configured in the shortcut for this Start Menu item.

You might have to change the property of WebSphere Application Server Administrative Console in Windows 2000 Start Menu (Start > Programs > IBM WebSphere > Application Server V5.0 > Administrative Console) as appropriate. For example change,

C:\Program Files\Internet Explorer\IEXPLORE.EXE http://<hostname>:9090/admin/

to

C:\Program Files\Internet Explorer\IEXPLORE.EXE http://<hostname>:9081/admin/

 

See also

Home |

 

WebSphere is a trademark of the IBM Corporation in the United States, other countries, or both.

 

IBM is a trademark of the IBM Corporation in the United States, other countries, or both.

 

Tivoli is a trademark of the IBM Corporation in the United States, other countries, or both.

 

AIX is a trademark of the IBM Corporation in the United States, other countries, or both.