E Troubleshooting OracleAS Web Cache

Startup Failures

This section describes workarounds to common startup failures:

• Problem 1: Port Conflicts

• Problem 2: OracleAS Web Cache Manager Inaccessible

• Problem 3: Mismatched Oracle Home Definitions

• Problem 4: Privileged Port Numbers

• Problem 5: More Then 1,024 Connections

• Problem 6: Opening Wallet

• Problem 7: Loading Library Object Files

• Problem 8: Permission Denied Error

Problem 1: 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 fails to start and port conflicts are reported to the event log file. The following shows an excerpt of the event log with port conflict event messages:

[25/Nov/2004:19:12:40 +0000] [notification 9612] [ecid: -]  OracleAS Web Cache 10g (10.1.2)
[25/Nov/2004:19:12:40 +0000] [notification 9403] [ecid: -] Maximum number of file/socket descriptors set to 950.
[25/Nov/2004:19:12:40 +0000] [notification 13002] [ecid: -] Maximum allowed incoming connections are 700
[25/Nov/2004:19:12:40 +0000] [alert 13305] [ecid: -] Failed to assign port 7777: Address already in use
[25/Nov/2004:19:12:40 +0000] [alert 9707] [ecid: -]  Failed to start the server.
[25/Nov/2004:19:12:40 +0000] [alert 9609] [ecid: -] The server process could not initialize.
[25/Nov/2004: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.

Solution 1

Typically, OracleAS Web Cache and the origin server ports are in conflict. To resolve port conflicts:

1. Verify the port assigned to OracleAS Web Cache from the Ports page of Application Server Control Console (Web Cache Home page > Administration tab > Properties > Web Cache > Ports) or the Listen Ports page of OracleAS Web Cache Manager (Ports > Listen Ports).

   If multiple instances of OracleAS Web Cache are running on a multihomed host with multiple IP addresses, a port conflict can occur. In OracleAS Web Cache Manager,

   The IP address for the default HTTP ports is set to * in Application Server Control Console and ANY in OracleAS Web Cache Manager. Upon startup, OracleAS Web Cache attempts to bind the ports to all IP addresses. If a port conflict occurs, change * or ANY to a specific IP address from the Listen Ports page of OracleAS Web Cache Manager.

2. Verify the host names and ports assigned to the origin servers from the Origin Servers page of Application Server Control Console (Web Cache Home page > Administration tab > Properties > Application > Origin Servers) or OracleAS Web Cache Manager (Origin Servers, Sites, and Load Balancing > Origin Servers).

3. Restart OracleAS Web Cache.

   
   

   See Also: "Starting and Stopping the Cache In an Oracle Application Server Configuration"

   
   

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/Nov/2004:19:21:42 +0000] [alert 13305] [ecid: -] Failed to assign port 4000: Address already in use
[25/Nov/2004:19:21:42 +0000] [alert 9707] [ecid: -]  Failed to start the server.
[25/Nov/2004:19:21:42 +0000] [alert 9609] [ecid: -] The server process could not initialize.
[25/Nov/2004: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>
...

Problem 2: OracleAS Web Cache Manager Inaccessible

OracleAS Web Cache Manager does not enforce stringent validation checking. This is especially a problem when the admin server process is shut down after applying invalid configuration changes. In that case, the admin server process will not be able to start up, and the OracleAS Web Cache Manager will become inaccessible. Check the event log file for startup errors or the Event Viewer on Windows.

Solution 2

To solve this problem:

• If you want to retain the configuration changes you made, send the webcache.xml file to Oracle Support to troubleshoot the invalid configuration entry.

  Do not edit this configuration file manually, except in the cases described in this guide, or when directed to do so by Oracle Support. Improper editing of this configuration file may cause problems in OracleAS Web Cache.

• If you want to restore configuration to a previous configuration, run the webcachectl reset command to restore to the previous version of the configuration. The opmnctl utility does not provide a reset command.

Problem 3: Mismatched Oracle Home Definitions

If the definition of Oracle home in the webcache.xml configuration file is different than the definition of Oracle home in your environment, OracleAS Web Cache may fail to start.

On UNIX, you may see the following alert message in the event log:

No matching CACHE element found in webcache.xml for current host name 
(webcache-host) and ORACLE_HOME (Oracle_home).

On Windows, you may see the following message:

The description for Event ID ( 1 ) in Source ( Oracle-Web-Cache ) cannot be
found. The local computer may not have the necessary registry information or
message DLL files to display messages from a remote computer. The following 
information is part of the event: Cannot open log files because NULL socket
indicates problem.

During installation, the Oracle home is written to the ORACLEHOME attribute of the CACHE NAME element in the webcache.xml file. The Oracle home is specified with the $ORACLE_HOME environment variable on UNIX and the ORACLE_HOME parameter located at HKEY_LOCAL_MACHINE\SOFTWARE\ORACLE in the Windows registry.

Solution 3

If there is a mismatch, modify either the ORACLEHOME attribute in the webcache.xml file or the Oracle home environment setting.

In a cluster environment, there is one CACHE NAME element in the webcache.xml file for each cluster member. Be sure to modify the correct element. After modification, propagate the configuration, as described in "Task 4: Propagate the Configuration to Cluster Members".

Problem 4: Privileged Port Numbers

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 with the root privilege.

If webcached is not run as root in a configuration with privileged ports, then the cache server process fails to start and messages similar to the following output are written to the event log file:

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

Solution 4

Problem 5: More Then 1,024 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/Nov/2004:19:30:48 +0000] [notification 9612] [ecid: -]  OracleAS Web Cache 10g (10.1.2)
[25/Nov/2004:19:30:48 +0000] [alert 9604] [ecid: -] Could not increase the number of file/socket descriptors to 2250. 
[25/Nov/2004:19:30:48 +0000] [alert 9707] [ecid: -]  Failed to start the server.

Solution 5

Problem 6: Opening Wallet

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

[25/Nov/2004:19:35:00 +0000] [warning 11917] [ecid: -] SSL wallet wallet file /etc/ORACLE/WALLETS/janedoe/ewallet.p12 does not exist
[25/Nov/2004: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/Nov/2004:19:35:00 +0000] [warning 11922] [ecid: -] Wallet wallet fails to open at location /etc/ORACLE/WALLETS/janedoe, NZERROR 28759, as user janedoe
[25/Nov/2004:19:35:00 +0000] [alert 9609] [ecid: -] The server process could not initialize.
[25/Nov/2004:19:35:00 +0000] [notification 9610] [ecid: -]  The server is exiting.

Solution 6

To resolve this error, perform the following procedure:

1. Ensure that the wallet directory exists:

   • /etc/ORACLE/WALLETS/user_name on UNIX

   • %USERPROFILE%\ORACLE\WALLETS on Windows

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

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

3. 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"

   
   

4. Restart OracleAS Web Cache with the following command:

   opmnctl restartproc ias-component=WebCache
   
   

5. Recheck the event log for wallet errors.

Problem 7: Loading Library Object Files

If during the installation or application of new a patch an object file becomes corrupted, OracleAS Web Cache fails to start. You may see an error similar to the following:

error while loading shared libraries: libclntsh.so.10.1: cannot open shared object file: No such file or directory

Solution

To resolve this error, relink the library

1. Set the ORACLE_HOME environment variable.

2. Go to the $ORACLE_HOME/webcache/lib directory.

3. Run the following command to relink the library

   make -f ins_calypso.mk install
   
   

4. If you are running OracleAS Web Cache with the root privilege, run webcache_setup.sh.

   
   

   See Also: "Running webcached with Root Privilege" for instructions on configuring the webcached executable to run with the root privilege

   
   

Problem 8: Permission Denied Error

If OracleAS Web Cache is started by a user that is running under a different group which does not have sufficient privileges to change user groups, a message similar to the following is report to the event log file:

Permission denied when setting group ID group_ID

The root user is the only user permitted to change the group ID of users.

Solution 8

The solution to this error depends upon one of the following possible causes:

• The opmnctl or webcachectl user does not match the configured process identity user in the Security page (Web Cache Home page > Administration tab > Properties > Application > Origin Servers) of Application Server Control Console or the Process Identity page (Properties > Process Identity) of OracleAS Web Cache Manager.

  If the intent is to use a group ID which is different from the group ID of OracleAS Web Cache, you must configure webcached to run as the root privilege using the setidentity or setroot command of webcache_setuser.sh.

  
  

  See Also: "Running webcached with Root Privilege" for instructions on using the setidentity or setroot command of webcache_setuser.sh

  
  

• The opmnctl or webcachectl user is running as the same group ID as OracleAS Web Cache, which is different from the one listed in the event log message.

  In this case, you must modify the group ID to the correct group in the Security page (Web Cache Home page > Administration tab > Properties > Application > Origin Servers) of Application Server Control Console or the Process Identity page (Properties > Process Identity) of OracleAS Web Cache Manager. To determine the correct group, log in to the computer using the opmnctl or webcachectl user, and then use the UNIX command id to determine the correct group ID.

• The opmnctl or webcachectl user is running as the same group ID as OracleAS Web Cache, which is the same as the one listed in the event log.

  To resolve this error, stop all the Oracle Application Server processes, and verify the group ID. Use the UNIX command id to determine the user and group ID. If the group ID matches the group ID in the event log message, then you can start the processes again.

Load Issues 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 effect occurs because OracleAS Web Cache performs light maintenance work, even when it is idle. One operation OracleAS Web Cache performs is garbage collection—removing the less popular and less valid objects from the cache in favor of the more popular and more valid objects. During idle mode, the following effect occurs:

• The uptime load—the average kernel scheduler queue length—is going to be longer. OracleAS Web Cache increases the average queue length (uptime output) by approximately one.

• The CPU load is still low because the work OracleAS Web Cache performs is minimal.

Performance Degradation and Memory

Because OracleAS Web Cache is an in-memory cache, it is best to deploy OracleAS Web Cache on a dedicated computer to minimize paging. Unless the computer is dedicated to run OracleAS Web Cache, ensure the maximum cache size does not exceed 20 percent of the total memory.

This section describes workarounds to invalidation timeouts:

• Problem 1: Paging

• Problem 2: OracleAS Web Cache Using Memory than the Maximum Cache Size

Problem 1: Paging

If the time taken to cache or invalidate objects increases, the computer may be paging. Paging can severely degrade performance.

Solution 1

To configure OracleAS Web Cache to work efficiently on a computer with paging, either deploy OracleAS Web Cache on a dedicated computer or reduce the maximum cache size and maximum cached object size from the Resource Limits and Timeouts page of Application Server Control Console (Web Cache Home page > Administration tab > Properties > Web Cache > Resource Limits and Timeouts) or the Resource Limits page of OracleAS Web Cache Manager (Properties > Resource Limits).

Problem 2: OracleAS Web Cache Using Memory than the Maximum Cache Size

If OracleAS Web Cache uses more memory than the maximum cache size, the increase may be caused by numerous simultaneous requests for objects that are larger than the maximum cached object size. In this situation, because the objects are not cached, OracleAS Web Cache uses more memory processing the requests and forwarding them to the origin server than it would to cache the objects.

Solution 2

Review access logs to determine if many simultaneous requests for large objects have been made and adjust the size of the maximum cached object size so that those objects are cached. In addition, check that a caching rule or response header specifies that the objects are to be cached.

To modify the maximum cache size or the maximum cached object size, set new limits from the Resource Limits and Timeouts page of Application Server Control Console (Web Cache Home page > Administration tab > Properties > Web Cache > Resource Limits and Timeouts) or the Resource Limits page of OracleAS Web Cache Manager (Properties > Resource Limits).

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.

This section describes workarounds to invalidation timeouts:

• Problem 1: Invalidation Timeouts in a Cache Hierarchy

• Problem 2: Invalidation Timeouts in a Cache Cluster

Problem 1: Invalidation Timeouts in a Cache Hierarchy

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/Nov/2004: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/Nov/2004: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'

Solution 1

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
   

Problem 2: Invalidation Timeouts in a Cache Cluster

When the timeout is exceeded in a cache cluster, a message similar to the following is displayed in the response to the invalidation request:

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

Solution 2

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. Propagate changes to all cache cluster members and restart the other cache cluster members.

   
   

   See Also: "Task 4: Propagate the Configuration to Cluster Members"

   
   

Capacity Issues on Origin Server

Problem

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 exceeded the maximum number of concurrent connections.

Solution

To resolve this problem, you can either:

• Increase capacity.

  In the Origin Servers page of Application Server Control Console (Web Cache Home page > Administration tab > Properties > Application > Origin Servers) or OracleAS Web Cache Manager (Origin Servers, Sites, and Load Balancing > Origin Servers), check the value of the Capacity field. This field provides the currently configured capacity. If the capacity can be adjusted, increase it.

  
  

  See Also: "Task 9: Configure Origin Server, Load Balancing, and Failover Settings"

  
  

• Evaluate the caching rules to determine if additional content can be cached.

  
  

  See Also: Chapter 12, "Creating Caching Rules"

  
  

Browsers Not Receiving Complete Responses

The browser is not receiving the complete response.

Problem

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.

Solution

For cache misses, there are two workarounds for the improper content-length problem:

• Fix your application to ensure that the value of the Content-Length response-header field is correct.

• Configure the browser or client emulator to send HTTP/1.0 requests without the Connection: keep-alive request-header field.

Browser Displaying a Page Not Displayed Error

Browsers return an error saying that a page cannot be displayed.

Problem

Microsoft Internet Explorer has known issues with trying to reuse SSL connections after they have timed out. Due to this limitation, users connecting to a Web site using Internet Explorer 5.5 or later release with the following OracleAS Web Cache configuration conditions, may receive an error saying that the page cannot be displayed:

• OracleAS Web Cache has at least one listener port to set to accept HTTPS browser requests

• The network connection keep-alive timeout is set a value more than 0.

When OracleAS Web Cache is configured with these settings, Internet Explorer may send HTTPS requests after OracleAS Web Cache has already tried to close the connection. Then, the browser returns an error saying that the page cannot be displayed.

Solution

To correct his problem, you can upgrade all clients to the use the correct Microsoft patches. For information about the Internet Explorer problem, its workarounds, and links to updates to Internet Explorer, see the following:

• Internet Explorer 5.5: http://support.microsoft.com/default.aspx?scid=kb;EN-US;q305217

• Internet Explorer 6: http://support.microsoft.com/default.aspx?kbid=831167

In configurations with public Web sites, this option may not feasible. For these configurations, the Web site administrator can either enable or disable keep-alive timeouts on HTTPS connections from Internet Explorer in the webcache.xml file. By default, OracleAS Web Cache disables keep-alive for HTTPS connections from Internet Explorer.

To re-enable keep-alive connection for HTTPS requests from Internet Explorer, perform the following steps. In a cache cluster, you must perform this procedure for each cluster member:

1. Use a text editor to open the webcache.xml file.

2. Locate the CALYPSONETINFO element:

   <CALYPSONETINFO...KEEPALIVE4MSIE_SSL="NO".../>
   
   

3. Modify the value of KEEPALIVE4MSIE_SSL attribute to YES.

4. Restart OracleAS Web Cache with the following command:

   opmnctl restartproc ias-component=WebCache
   

End-User Performance Monitoring Issues

This section describes workarounds to end-user performance monitoring:

• Problem 1: Cookie and JavaScript in Pages Monitored by End-User Performance Monitoring

• Problem 2: Not Enough Data in Access Logs for End-User Performance Monitoring

Problem 1: Cookie and JavaScript in Pages Monitored by End-User Performance Monitoring

End-user performance monitoring creates an additional cookie and inserts JavaScript into pages. The application may generate cookies and JavaScript that conflict with additional cookies and JavaScript created by end-user performance monitoring.

Solution

If this behavior causes a problem for an application, then disable this feature from the End-User Performance Monitoring page of Application Server Control Console (Web Cache Home page > Administration tab > Properties > Web Cache > End-User Performance Monitoring) or OracleAS Web Cache Manager (Logging and Diagnostics > End-User Performance Monitoring).

Problem 2: Not Enough Data in Access Logs for End-User Performance Monitoring

You attempt to gather end-user performance monitoring data and receive an error about the access logs not containing enough data. This error can be the result of a configuration error.

Solution 2

To resolve this error:

1. Check that the End-User Performance Monitoring Format is configured as the logging format for the site.

   
   

   See Also: "Configuring Access Logs"

   
   

2. Ensure end-user performance monitoring is configured for the site.

   
   

   See Also: "Enabling End-User Performance Monitoring"

   
   

3. Check the site-to-server mappings.

   
   

   See Also: "Map Sites to Origin Servers"

   
   

XML Parsing Errors of webcache.xml Appears in Event Viewer

XML parsing errors related to not being able to read the webcache.xml file are displayed to the Event Viewer rather than to the screen on Windows.

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/Nov/2004: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/Nov/2004:16:02:12 -0500] [error 12086] [ecid: 25732665668,0] ESI syntax error. Unrecognized keyword exclude is at line 2. 
[24/Nov/2004:16:02:12 -0500] [warning 11064] [ecid: 25732665668,0] ESI object
 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/Nov/2004: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/Nov/2004:16:10:40 -0500] [error 12086] [ecid: 25733186204,0] ESI syntax error. Unrecognized keyword exclude is at line 2. 
[24/Nov/2004:16:10:40 -0500] [warning 11064] [ecid: 25733186204,0] ESI object www.company.com:80/cgi-bin/esi-headers.sh?/esi/frag_exclusion.html parsing error 
[24/Nov/2004: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/Nov/2004: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/Nov/2004: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/Nov/2004: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/Nov/2004:16:14:41 -0500] [error 12086] [ecid: 25733432444,0] ESI syntax error. Unrecognized keyword exclude is at line 2.
[24/Nov/2004:16:14:41 -0500] [warning 11064] [ecid: 25733432444,0] ESI object www.company.com:80/cgi-bin/esi-headers.sh?/esi/frag_exclusion.html parsing error 
[24/Nov/2004: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:

• T means this page is composed an ESI template.

• U means this request resulted in an update of stale object.

• max-age=30+60 means that the object is to expire in 30 seconds from population and to be removed from the cache 60 seconds from the expiration. This provides a total of 90 seconds from population.

• age=0 in age means that 0 seconds have passed since population of the cache, meaning there are 30 seconds to expiration and 60 seconds to removal.

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

• F means this page is an ESI fragment.

• U means this request resulted in a cache miss.

• max-age=30+0 means that the object is to expire in 30 seconds from population and to be removed from the cache 0 seconds from the expiration. This provides a total of 30 seconds from population.

• age=0 in age means that 0 seconds have passed since population of the cache, meaning there are 30 seconds to expiration and removal.

Web Cache Debug Info: Web Cache Debug Info: TU;max-age=30+60;age=0 
Simple inclusion test: Web Cache Debug Info: Web Cache Debug Info: TU;max-age=30+60;age=0 
Web Cache Debug Info: FM;max-age=30+0;age=0 

[EVENTLOG] 
[24/Nov/2004:16:17:23 -0500] [detail] [ecid: 25733598670,0] [client: 127.0.0.1] [host: www.company.com:80] [url: /cgi-bin/esi-headers.sh?/esi/inclusion_exclusion.html] 
[24/Nov/2004:16:17:23 -0500] [error 12086] [ecid: 25733598670,0] ESI syntax error. Unrecognized keyword exclude is at line 2. 
[24/Nov/2004:16:17:23 -0500] [warning 11064] [ecid: 25733598670,0] ESI object www.company.com:80/cgi-bin/esi-headers.sh?/esi/frag_exclusion.html parsing error 
[24/Nov/2004:16:17:23 -0500] [warning 12009] [ecid: 25733598670,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 
Simple inclusion succeeded.