Skip Headers

Oracle Application Server Web Cache Administrator's Guide
10g (9.0.4)

Part Number B10401-01
Go To Documentation Library
Home
Go To Product List
Solution Area
Go To Table Of Contents
Contents
Go To Index
Index

Go to previous page Go to next page

14
Troubleshooting OracleAS Web Cache Configuration

This chapter describes common configuration problems and debugging techniques for resolving them.

This chapter contains these topics:

Startup Failures

If OracleAS Web Cache does not start, it can be because of the following problems:

Port Conflicts

During configuration, you configure listening ports from which OracleAS Web Cache receives browser requests. By default, the port is 7777 for HTTP requests. You can configure a port for HTTPS requests.

You also configure listening ports for administration, invalidation, and statistics monitoring requests. By default, the HTTP ports are 4000, 4001, and 4002, respectively. You also configure the advertised port number from which an origin server can receive OracleAS Web Cache requests.

When you start OracleAS Web Cache, a port conflict check is performed. If there is a port conflict, OracleAS Web Cache will fail to start. Port conflicts are reported to the event log file, event_log. The event_log file is located in $ORACLE_HOME/webcache/logs on UNIX and in ORACLE_HOME\webcache\logs on Windows. The following shows an excerpt of event_log with port conflict event messages:

[25/Jun/2003:19:12:40 +0000] [notification 9612] [ecid: -]  OracleAS Web Cache 
version number: 9.0.4
[25/Jun/2003:19:12:40 +0000] [notification 9403] [ecid: -] Maximum number of 
file/socket descriptors set to 950.
[25/Jun/2003:19:12:40 +0000] [notification 13002] [ecid: -] Maximum allowed 
incoming connections are 700
[25/Jun/2003:19:12:40 +0000] [alert 13305] [ecid: -] failed to assign port 7777, 
bind() error = Address already in use
[25/Jun/2003:19:12:40 +0000] [alert 9707] [ecid: -]  Failed to start the server.
[25/Jun/2003:19:12:40 +0000] [alert 9609] [ecid: -] The server process could not 
initialize.
[25/Jun/2003:19:12:40 +0000] [notification 9610] [ecid: -]  The server is 
exiting.

Note that the last message will only appear when the admin server process is started for the first time.

To resolve port conflicts:

  1. Use OracleAS Web Cache Manager to resolve the port conflicts.

    Typically, OracleAS Web Cache and the origin server ports are in conflict. Verify the port assigned to OracleAS Web Cache in Listen Ports page (Ports > Listen Ports), and verify the host names and ports assigned to the origin servers in the Origin Servers page (Origin Servers, Sites, and Load Balancing > Origin Servers).

    If multiple instances of OracleAS Web Cache are running on a multihomed host with multiple IP addresses, a port conflict can occur. The IP address for the default HTTP and HTTPS ports is set to ANY. Upon startup, OracleAS Web Cache attempts to bind the ports to all IP addresses. If a port conflict occurs, change ANY to a specific IP address in the Listen Ports page (Ports > Listen Ports).

  2. Restart OracleAS Web Cache.

    See Also:

    "Starting and Stopping OracleAS Web Cache"

If the administration port is in conflict, the admin server process will not start and OracleAS Web Cache Manager will not be accessible. The event log will contain messages that resemble the following output:

[25/Jun/2003:19:21:42 +0000] [alert 13305] [ecid: -] failed to assign port 4000, 
bind() error = Address already in use
[25/Jun/2003:19:21:42 +0000] [alert 9707] [ecid: -]  Failed to start the server.
[25/Jun/2003:19:21:42 +0000] [alert 9609] [ecid: -] The server process could not 
initialize.
[25/Jun/2003:19:21:42 +0000] [notification 9610] [ecid: -]  The server is 
exiting.

To resolve this port conflict, modify the webcache.xml file, an internal file that contains the configuration settings, and change the administration port number. The webcache.xml file is located in $ORACLE_HOME/webcache on UNIX and in ORACLE_HOME\webcache on Windows. The following shows an excerpt of the webcache.xml file with the line for the administration port shown in boldface:

...
  <MULTIPORT>
    <LISTEN IPADDR="ANY" PORT="1100" PORTTYPE="NORM"/>
    <LISTEN IPADDR="ANY" PORT="4000" PORTTYPE="ADMINISTRATION"/>
    <LISTEN IPADDR="ANY" PORT="4003" PORTTYPE="INVALIDATION"/>
    <LISTEN IPADDR="ANY" PORT="4002" PORTTYPE="STATISTICS"/>
  </MULTIPORT>
...

Privileged Ports

Port numbers less than 1024 are reserved for use by privileged processes on UNIX. If you want to configure OracleAS Web Cache to listen on a port less than 1024, such as on port 80, then the webcached executable must run as the root user.

See:

"Running webcached with Root Privilege" for instructions on configuring the webcached executable to run as root.

If webcached is not run as root, the cache server process fails to start and messages similar to the following output are written to the event log file:

[25/Jun/2003:19:27:04 +0000] [notification 9612] [ecid: -]  OracleAS Web Cache 
version number: 9.0.4
[25/Jun/2003:19:27:04 +0000] [notification 9403] [ecid: -] Maximum number of 
file/socket descriptors set to 950.
[25/Jun/2003:19:27:04 +0000] [notification 13002] [ecid: -] Maximum allowed 
incoming connections are 700
[25/Jun/2003:19:27:04 +0000] [alert 13305] [ecid: -] failed to assign port 80, 
bind() error = Permission denied
[25/Jun/2003:19:27:04 +0000] [alert 9707] [ecid: -]  Failed to start the server.
[25/Jun/2003:19:27:04 +0000] [alert 9609] [ecid: -] The server process could not 
initialize.
[25/Jun/2003:19:27:04 +0000] [notification 9610] [ecid: -]  The server is 
exiting.

Greater Than One Thousand Maximum Connections

For OracleAS Web Cache to support more than 1,024 connections on UNIX, the webcached executable must run with the root privilege.

If webcached cannot run with the root privilege, the cache server process fails to start and messages that resemble the following output are written to the event log file:

[25/Jun/2003:19:30:48 +0000] [notification 9612] [ecid: -]  OracleAS Web Cache 
version number: 9.0.4
[25/Jun/2003:19:30:48 +0000] [alert 9604] [ecid: -] Could not increase the 
number of file/socket descriptors to 2250. 
[25/Jun/2003:19:30:48 +0000] [alert 9707] [ecid: -]  Failed to start the server.

See Also:

Wallet Cannot Be Opened

When OracleAS Web Cache is unable to open a wallet, messages similar to the following output are written to the event log file:

[25/Jun/2003:19:35:00 +0000] [warning 11917] [ecid: -] SSL wallet Wallet file 
/etc/ORACLE/WALLETS/janedoe/ewallet.p12 does not exist
[25/Jun/2003:19:35:00 +0000] [warning 11917] [ecid: -] SSL wallet Wallet file 
/etc/ORACLE/WALLETS/janedoe/ewallet.der does not exist
[25/Jun/2003:19:35:00 +0000] [warning 11919] [ecid: -] SSL wallet Autologin file 
/etc/ORACLE/WALLETS/janedoe/cwallet.sso does not exist -  Wallet does not appear 
to be autologin wallet.
[25/Jun/2003:19:35:00 +0000] [warning 11922] [ecid: -] Wallet wallet fails to 
open at location /etc/ORACLE/WALLETS/janedoe, NZERROR 28759, as user janedoe
[25/Jun/2003:19:35:00 +0000] [alert 9609] [ecid: -] The server process could not 
initialize.
[25/Jun/2003:19:35:00 +0000] [notification 9610] [ecid: -]  The server is 
exiting.

To resolve this error, perform the procedure that follows. At the end of each step, restart OracleAS Web Cache with the following command:

opmnctl restartproc ias-component=WebCache

Then, recheck the event log for wallet errors.

  1. If you installed OracleAS Web Cache as a standalone product on Windows, follow the "Enabling Wallets to Open on Windows" to ensure that the wallet can be opened at startup.

  2. Ensure that the wallet directory exists:

    • /etc/ORACLE/WALLETS/user_name on UNIX

    • %USERPROFILE%\ORACLE\WALLETS on Windows

  3. Ensure that the auto-login file cwallet.sso and wallet file ewallet.p12 exist.


    Note:

    If you create a wallet using Oracle Application Server, the wallet file is named ewallet.der.


    If these files do not exist, then an auto-login wallet does not exist. In this case, create the wallet.

    See Also:

    "Task 1: Create Wallets"

    If these files do exist, then the wallet user may not match the OracleAS Web Cache user. Continue to Step 4.

  4. Change the owner of the wallet. On UNIX, change it to the user ID and group ID specified in the Process Identity page (Properties > Process Identity) of the OracleAS Web Cache Manager. On Windows, change it to the user that installed OracleAS Web Cache.

    Note, if this is a standalone installation of OracleAS Web Cache, not part of an Oracle Application Server installation, the owner is the owner of OracleHOME_NAMEWebCache service on Windows operating systems.

    See Also:

    "Task 2: Modify Security Settings"

  5. Confirm that the wallet was not copied from one computer to another.

    See Also:

  6. Ensure that Oracle Wallet Manager can open the wallet.

    If Oracle Wallet Manager cannot open the wallet, then the wallet is corrupt. In this case, re-create the wallet.

    See Also:

    "Task 1: Create Wallets"

Caching Rules

To diagnose if caching rules are set up to serve wrong or outdated content:

  1. Analyze the content of the event_log file and the access_log file in $ORACLE_HOME/webcache/logs on UNIX and in ORACLE_HOME\webcache\logs on Windows.

    See Also:

    Chapter 12 for further information about logging

  2. Determine the contents of the cache by:

  3. Compare the contents of the cache to the caching rules in the Caching, Personalization, and Compression Rules page (Rules for Caching, Personalization, and Compression > Caching, Personalization, and Compression Rules) to determine discrepancies.

  4. Adjust caching rules by adding or removing rules, adjusting expression type syntax, or changing the precedence of rules.

    See Also:

    Chapter 9, "Creating Caching Rules"

Common Edge Side Includes (ESI) Syntax Errors

The majority of ESI errors are the result of syntax errors in either the template or fragment pages. By analyzing the ESI output in the event log, you can easily diagnose most ESI syntax errors. To avoid unnecessary reporting in the event log, use a verbosity level of WARNING. In addition to the event log, it is useful to display the diagnostic information and event log information in the HTML response body.

See Also:

The following topics describe using the event log and HTML response body to diagnose template and fragment syntax errors:

Template Syntax Error Example

Consider a template named exlusion.html that contains syntax for a nonexistent ESI tag named <esi:exclude>:

<html><body> 
Simple inclusion test.
<esi:exclude src="/cgi-bin/esi-headers.sh?/esi/fragment1.html"/> 
</body></html> 

The response returned to the browser follows:

<HTML><HEAD><TITLE>Unsupported ESI feature</TITLE></HEAD> 
<BODY>Some ESI features on this page are not supported. 
</BODY></HTML> 

The following shows an event log excerpt that indicates a problem with the <esi:exlude> keyword:

[24/Mar/2003:16:02:12 -0500] [detail] [ecid: 25732665668,0] [client: 127.0.0.1] 
[host: www.company.com:80] [url: /cgi-bin/esi-headers.sh?/esi/exclusion.html] 
[24/Mar/2003:16:02:12 -0500] [error 12086] [ecid: 25732665668,0] ESI syntax 
error. Unrecognized keyword exclude is at line 2. 
[24/Mar/2003:16:02:12 -0500] [warning 11064] [ecid: 25732665668,0] ESI document 
www.company.com:80/cgi-bin/esi-headers.sh?/esi/exclusion.html parsing error 

Fragment Syntax Error Example

Consider a template named inclusion_exclusion.html that contains the following syntax for including fragment exlusion1.html. Notice that HTML does not contain any ESI exception handling tags or attributes.

<html><body> 
Simple inclusion test.
<esi:include src="/cgi-bin/esi-headers.sh?/esi/frag_exclusion.html"/> 
</body></html> 

Fragment frag_exclusion.html contains syntax for a nonexistent ESI tag named <esi:exclude>:

<esi:exclude src="/cgi-bin/esi-headers.sh?/esi/fragment1.html"/> 

The response returned to the browser follows:

<HTML><HEAD><TITLE>ESI Processing Exception</TITLE></HEAD> 
<BODY>The page caused an ESI processing exception. 
</BODY></HTML> 

The following shows an event log excerpt that indicates a problem with the <esi:exlude> keyword. As a result of this error and the fact that the ESI in the template does not specify any alternative fragment to serve, the browser is served an ESI exception.

[24/Mar/2003:16:10:40 -0500] [detail] [ecid: 25733186204,0] [client: 127.0.0.1] 
[host: www.company.com:80] [url: /cgi-bin/esi-headers.sh?/esi/inclusion_
exclusion.html] 
[24/Mar/2003:16:10:40 -0500] [error 12086] [ecid: 25733186204,0] ESI syntax 
error. Unrecognized keyword exclude is at line 2. 
[24/Mar/2003:16:10:40 -0500] [warning 11064] [ecid: 25733186204,0] ESI document 
www.company.com:80/cgi-bin/esi-headers.sh?/esi/frag_exclusion.html parsing error 
[24/Mar/2003:16:10:40 -0500] [warning 12009] [ecid: 25733186204,0] Incorrect ESI 
fragment exception in ESI template 
www.company.com:80/cgi-bin/esi-headers.sh?/esi/inclusion_exclusion.html, 
fragment www.company.com:80/cgi-bin/esi-headers.sh?/esi/frag_exclusion.html 
[24/Mar/2003:16:10:40 -0500] [error 12012] [ecid: 25733186204,0] No exception 
handler is defined in template 
www.company.com:80/cgi-bin/esi-headers.sh?/esi/inclusion_exclusion.html:. 
[24/Mar/2003:16:10:40 -0500] [error 11368] [ecid: 25733186204,0] ESI exception 
error response is returned. 

Fragment Syntax Error with Exception Handling Example

Consider the same inclusion_exclusion.html template that contains the following syntax for including fragment frag_exclusion.html or alternative fragment fragment1.html. When the exlusion1.html fragment specified cannot be fetched, the fragment1.html fragment specified with the alt attribute is served in its place.

<html><body> 
Simple inclusion test.
<esi:include src="/cgi-bin/esi-headers.sh?/esi/frag_exclusion.html" 
alt="/esi/fragment1.html"/> 
</body></html> 

Fragment frag_exclusion.html contains syntax for a nonexistent ESI tag named <esi:exclude>:

Simple inclusion succeeded.
<esi:exclude src="/cgi-bin/esi-headers.sh?/esi/fragment1.html"/> 

Therefore, fragment fragment1.html is used instead of frag_exclusion.html as the fragment:

Simple inclusion succeeded.

The response returned to the browser follows:

<html><body> 
Simple inclusion test. Simple inclusion succeeded. 
</body></html> 

The following shows an event log excerpt that indicates a problem with the <esi:exlude> keyword. Because of the exception handling, the browser is served the alternative fragment instead of an ESI exception.

[24/Mar/2003:16:14:41 -0500] [detail] [ecid: 25733432444,0] [client: 127.0.0.1] 
[host: www.company.com:80] [url: /cgi-bin/esi-headers.sh?/esi/inclusion_
exclusion.html] 
[24/Mar/2003:16:14:41 -0500] [error 12086] [ecid: 25733432444,0] ESI syntax 
error. Unrecognized keyword exclude is at line 2. 
[24/Mar/2003:16:14:41 -0500] [warning 11064] [ecid: 25733432444,0] ESI document 
www.company.com:80/cgi-bin/esi-headers.sh?/esi/frag_exclusion.html parsing error 
[24/Mar/2003:16:14:41 -0500] [warning 12009] [ecid: 25733432444,0] Incorrect ESI 
fragment exception in ESI template 
www.company.com:80/cgi-bin/esi-headers.sh?/esi/inclusion_exclusion.html, 
fragment www.company.com:80/cgi-bin/esi-headers.sh?/esi/frag_exclusion.html 

In addition to analyzing the event log for the sequence of events, you can also view the diagnostic and event log results in the HTML response. The following shows the HTML response when the string +wcdebug is appended is the URL. The template diagnostic information, TU;max-age=30+60;age=0, means the following:

The fragment diagnostic information, FM;max-age=30+0;age=0, means the following:

Load on OracleAS Web Cache Computer

On UNIX operating systems, the top and uptime utilities report a higher than expected average load when the OracleAS Web Cache computer is idle. This occurs because OracleAS Web Cache performs light maintenance work, even when it is idle. During idle mode, the following effect occurs:

Invalidation Timeouts

The invalidation feature has a default timeout of 300 seconds for the propagation of invalidation requests in the cache hierarchy or cache cluster deployments.

See Also:

"Caching Dynamically Generated Content" for an overview of invalidation propagation

When the timeout is exceeded in a cache hierarchy, a message similar to the following is written to the event_log file of the remote cache or subscriber cache:

[28/Jan/2003:01:10:16 +0000] [debug 11739] [ecid: 25088352784,1] New
subscriber OracleAS Web Cache with IP '130.35.45.41' port '22000'
has been established. Total subscriber(s): '1'.
...
[28/Jan/2003:01:12:31 +0000] [notification 11734] [ecid: -]
Invalidation sent to subscriber cache with IP '130.35.45.41' port
'22002' has returned with response code: 'failed-no response code'

To resolve this error:

  1. On the central or provider cache, use a text editor to open the webcache.xml file.

  2. Locate the CALYPSONETINFO element:

    <CALYPSONETINFO...INV_PEER_TIMEOUT="300"
                    INV_GLOBAL_TIMEOUT="300".../>
    
    
  3. Modify the value of the INV_GLOBAL_TIMEOUT attribute to a larger value.

    The higher the value, the more system resources that will be used. If the network is fast, only increase the value to what is needed.

  4. Restart OracleAS Web Cache with the following command:

    opmnctl restartproc ias-component=WebCache
    
    

When the timeout is exceeded in a cache cluster, a message similar to the following is displayed in the Cache Cleanup Results dialog box or in the response to the invalidation request:

Can't connect to the web cache's invalidation listening port.

To resolve this error:

  1. On cache cluster members, use a text editor to open the webcache.xml file.

  2. Locate the CALYPSONETINFO element:

    <CALYPSONETINFO...INV_PEER_TIMEOUT="300"
                    INV_GLOBAL_TIMEOUT="300".../>
    
    
  3. Modify the value of INV_PEER_TIMEOUT attribute.

    In a cache cluster, it is likely that cache cluster members are running in a LAN environment. Therefore, decreasing the value of INV_PEER_TIMEOUT will typically improve efficiency.

  4. Restart OracleAS Web Cache with the following command:

    opmnctl restartproc ias-component=WebCache
    
    
  5. From OracleAS Web Cache Manager, propagate changes to all cache cluster members and restart the other cache cluster members.

    See Also:

    "Task 4: Propagate the Configuration to Cluster Members"

Application Web Server Capacity

If an application Web server has reached capacity, the following error message appears when accessing pages of a Web site:

The application Web server is busy. Possible reach capacity.

This error indicates that the application Web server has reached capacity--that is, the number of concurrent connections has been exceeded. To resolve this problem, you can either:

Content-Length Request-Header Field

If the actual length of a page is less than value of the Content-Length response-header field set by the origin server and sent to a browser by OracleAS Web Cache, the browser expects more data to arrive and the connection will eventually time out. If the actual length of the page is greater than the Content-Length, the browser will not receive the complete page. This problem does not occur for cache hits because OracleAS Web Cache correctly calculates the content length itself for pages stored in the cache. For cache misses, there are two workarounds for the improper content-length problem:

HTTP 500 Response Status Codes

OracleAS Web Cache does not cache pages that generate HTTP 500 response status codes. However, if an application reports an exception and does not send the error code, the exception may be cached by OracleAS Web Cache.

When you are developing a servlet and JSP and want to cache the content of the servlet and JSP, ensure that you send an non-200 HTTP error code in the runtime exception handling code. Otherwise, if the document has a caching rule associated with it, OracleAS Web Cache caches the document with the exception until the document is invalidated.

If you are using the Oracle JSP container in a Jserv environment as your JSP engine and servlet engine, Oracle JSP will generate HTTP 200 status code exceptions when a JSP file is not found or there is a compilation error in a JSP file. This is mainly for ease of debugging of JSP development in a JServ environment.

To enable the Oracle JSP container to generate an HTTP 404 Not Found or 500 response status codes rather than HTTP 200 status codes, set send_error to true and unsafe_reload to true in zone.properties in your JServ deployment environment. The file zone.properties is located in $ORACLE_HOME/Apache/Jserv/etc on UNIX or ORACLE_HOME\Apache\Jserv\etc on Windows.

When using the OC4J JSP container in OC4J environment, it is not necessary to establish these settings. OC4J always sends 500 status codes when it encounters a compilation error.

See Also:

Browser-Specific Issues

Table 14-1 describes browser limitations and their impact on OracleAS Web Cache.

Table 14-1  Browser Issues
Problem Description

Compressing JavaScript files

Problem Description: Compressed JavaScript files cause some browsers to behave erratically and possibly fail. This issue only affects files that are referenced with the src attribute of the script tag; it does not include files that contain inline JavaScripts.

Known browsers effected: Netscape, Internet Explorer 5.5

Example: <script language="JavaScript" src="copyright.js"></script>

If copyright.js is compressed for Netscape, the browser may fail.

Note: Even if compression is enabled, OracleAS Web Cache does not compress documents with included JavaScript files for these browsers.

Compressing documents with Content-Disposition response-header fields

Problem Description: Documents with Content-Disposition response-header fields show incorrect file names when they are compressed.

Known browsers effected: Internet Explorer 5.0, 5.5, and 6.0

Example: Response headers for URL /reportgen include to following:

Content-Type: application/excel

Content-Disposition: attachment; filename="file.csv"

When the document is not compressed, a Save As dialog appears with file.csv as the default filename. However, if it is compressed, reportgen appears as the default name. Without the correct extension, the file will not open correctly on Windows operating systems.

Note: Even if compression is enabled, OracleAS Web Cache does not compress documents containing a Content-Disposition response-header field.

Decompressing documents with Content-Disposition response-header fields

Description: Documents with Content-Disposition response-header fields are not decompressed when you choose File > Save As from Netscape browsers.

Known browsers effected: Netscape 4.x

Note: Even if compression is selected, OracleAS Web Cache does not compress documents containing a Content-Disposition response-header field.

Compressing style sheets

Description: Compressed style sheets can cause background attributes, such as background images, to not appear in the output.

Known browsers effected: Netscape, Internet Explorer 5.5

Note: Even if compression is enabled, OracleAS Web Cache does not compress documents with included style sheet files for these browsers.

Keep-Alive

Problem Description: For HTTPS requests, Internet Explorer 5.5 may send requests after OracleAS Web Cache has already tried to close the connection.

Known browsers effected: Internet Explorer 5.5

Workaround: Disable keep-alive by setting Keep-Alive to 0 in the Network Timeouts page (Properties > Network Timeouts) of the OracleAS Web Cache Manager. This closes the connection between OracleAS Web Cache and the browser after the browser returns a response.


Go to previous page Go to next page
Oracle
Copyright © 2002, 2003 Oracle Corporation.

All Rights Reserved.
Go To Documentation Library
Home
Go To Product List
Solution Area
Go To Table Of Contents
Contents
Go To Index
Index