Appendix D Troubleshooting Your Portal Deployment

This appendix describes how to troubleshoot the Sun Java™ System Portal Server software and the Sun Java System Portal Server Secure Remote Access (SRA) software.

Troubleshooting Portal Server

Troubleshooting SRA

Troubleshooting Portal Server

This sections contains troubleshooting information for Sun Java System Portal Server.

UNIX Processes

For the portal to be functioning properly, check that the following root-owned processes are running. Use the ps command to see this output.

Log Files

Recovering the Search Database

The Search database maintains recoverable transaction logs. Thus, under normal circumstances, you do not have to do anything to recover the database. Recovery from errors and transient conditions such as a full disk are straight forward. If desired, maintain Search database archives and restore from an archive in case you lost the entire database. In this scenario, you would copy the archive to the original database to recover it.

To Recover the Database

Stop all processes accessing the database, including the Portal Server instance.

Use the rdmgr -R command to recover.

Working with the Display Profile

If you need to troubleshoot the XML contents of your portal’s display profile, extract the contents to a file for examination. At some point in the troubleshooting process, it might be useful to reload the display profile.

To Extract the Display Profile

Use the dpadmin command to extract the display profile. For example:

./dpadmin list -u "uid=amAdmin,ou=People,o=sesta.com,o=isp" -w password -d "o=sesta.com,o=isp" > /tmp/displayxml

This example puts the contents of the display profile into the /tmp/displayxml file.

To Reload the Display Profile

Use the dpadmin command to reload the display profile. For example:

./dpadmin modify -u "uid=amAdmin,ou=People,o=sesta.com,o=isp" -w password -d "o=sesta.com,o=isp" /tmp/updated_displayxml

This example reloads the contents of the display profile from the /tmp/updated_displayxml file.

High CPU Utilization for Portal Server Instance

When using the Cisco Content Services Switch, you might see a very high CPU utilization on the Portal Server instance with Sun Java System Web Server error file showing the following message every five seconds.

The cause of this error is a “sticky bit” setting within the Cisco Content Services Switch that is causing these errors. These load balancers periodically ping the servers (every five seconds) to verify that the servers are alive. After turning off the “sticky bit” setting, which disables the ping to the server every 5 seconds, the errors will no longer show up in the Web Server product.

Configuring a Sun Java System Portal Server Instance to Use an HTTP Proxy

If the Portal Server software is installed on a host that cannot directly access certain portions of the Internet or your intranet, you can receive errors. For example, when using the SampleSimpleWebService provider, you might see the following error when the proxy has not been configured:

To Configure Usage of an HTTP Proxy for a Portal Server Instance

Change directories to the portal server install root directory containing the configuration for the instance.

cd portal-server-install-root/SUNWam/servers/https-servername/config

Edit the server.xml file within this directory and add the following lines:

http.proxyHost=proxy-host

http.proxyPort=proxy-port

http.nonProxyHosts=portal-host

where proxy-host is the fully-qualified domain name of the proxy host, proxy-port is the port on which the proxy is run, and portal-host is the fully qualified domain name of the portal host.

Troubleshooting SRA

This section describes how to capture information that Sun Java System support personnel need to troubleshoot problems in your deployment.

Debugging the Gateway

To turn debugging on or off, you set the level of debugging or set it to off. The following steps describe what to do.

gateway-install-root/SUNWam/config/AMConfig-instance-name.properties

Set the debug level:

com.iplanet.services.debug.level=

The debug levels are:

error - Only serious errors are logged in the debug file. Rewriter usually stops functioning when such errors occur.

warning - Warning messages are logged.

message - All debug messages are logged.

off - No debug messages are logged.

Specify the directory for the debug files in the following property of the AMConfig-instance-name.properties file:

com.iplanet.services.debug.directory=/var/opt/SUNWam/debug

where /var/opt/SUNWam/debug is the default debug directory.

Restart the Gateway from a terminal window:

gateway-install-root/SUNWps/bin/gateway -n gateway-profile-name start

Introduction to shooter

The shooter tool captures all the information that the development and support team will require to troubleshoot problems in your deployment of the Sun Java System Portal Server Secure Remote Access product. You can also run this tool on a Portal Server machine.

Installation type - determines if the installation has Sun Java System Portal Server with Sun Java System Secure Remote Access core, or Portal Server with SRA

System configuration related information -determines the host, domain, operating system, version, CPU type and speed, clock speed, and memory available

Processors, processor sets, and the SRA processes bound to them

SRA installation log

The platform.conf file(s)

The settings in the Gateway script such as the JVM™ settings including heap usage, and library path

Gateway service settings

Tuning settings in various files used for configuring Sun Java System Access Manager, Sun Java System Directory Server, and Sun Java System Web Server.

Output of the garbage collection

A memory or process footprint while the Gateway was being used

Formatted debug log files

Rewriter rulesets



Note	This tool collects information only for the instance of the Gateway that you specified during installation.

Using shooter

shooter.sh

This is the main script. Run this script after a test or just before starting a test on the SRA installation.

gctool.pl

To run gctool, start the Gateway, and type the following to redirect the output to this script and allow collection throughout the test.



Note	Before running gctool, ensure that you include -verbose:gc in the Gateway script in the “CMD” section. The Gateway script resembles the following: -server -verbose:gc -Xms1G -Xmx2G -XX:+OverrideDefaultLibthread -XX:ThreadStackSize=128 -XX:MaxPermSize=128M -XX:PermSize=128M -XX:MaxNewSize=256M -XX:NewSize=256M

At the end of the test period, run shooter to collect the output of gctool along with other data.

memfoot.sh

This script tracks the memory footprint of a process. Start this script after starting the Gateway and allow it to run during the duration of the test. The largest process with the given name or PID is tracked after every specified number of seconds.

The output of this script is a time-stamped process status file. The shooter tool collects this output along with the rest of the data.

uniq.pl

This script is used internally by shooter to find unique lines and their count. The advantage over the system uniq script is that it finds non-adjacent unique lines.

GWDump.class

This class is called internally by shooter to obtain the Gateway settings in the Access Manager administration console.

Previous Contents Index Next
Sun Java System Portal Server 6 2005Q1 Deployment Planning Guide