Oracle® Application Server Web Cache Administrator's Guide
10g Release 2 (10.1.2) B14046-04 |
|
Previous |
Next |
This appendix describes common problems that you might encounter when using OracleAS Web Cache and explains how to solve them. It contains the following topics:
This section describes common problems and solutions. It contains the following topics:
This section describes workarounds to common startup failures:
Problem 1: Port Conflicts
During configuration, you configure listening ports from which OracleAS Web Cache receives client 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 9400, 9401, and 9402, 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/Jul/2005:19:12:40 +0000] [notification 9612] [ecid: -] OracleAS Web Cache 10g (10.1.2)
[25/Jul/2005:19:12:40 +0000] [notification 9403] [ecid: -] Maximum number of file/socket descriptors set to 950.
[25/Jul/2005:19:12:40 +0000] [notification 13002] [ecid: -] Maximum allowed incoming connections are 700
[25/Jul/2005:19:12:40 +0000] [alert 13305] [ecid: -] Failed to assign port 7777: Address already in use
[25/Jul/2005:19:12:40 +0000] [alert 9707] [ecid: -] Failed to start the server.
[25/Jul/2005:19:12:40 +0000] [alert 9609] [ecid: -] The server process could not initialize.
[25/Jul/2005: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:
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.
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).
Restart 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/Jul/2005:19:21:42 +0000] [alert 13305] [ecid: -] Failed to assign port 9400: Address already in use
[25/Jul/2005:19:21:42 +0000] [alert 9707] [ecid: -] Failed to start the server.
[25/Jul/2005:19:21:42 +0000] [alert 9609] [ecid: -] The server process could not initialize.
[25/Jul/2005:19:21:42 +0000] [notification 9610] [ecid: -] The server is exiting.
To resolve this port conflict, modify the webcache.xml
file. 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="7777" PORTTYPE="NORM"/>
<LISTEN IPADDR="ANY" PORT="9400" PORTTYPE="ADMINISTRATION"/>
<LISTEN IPADDR="ANY" PORT="9401" PORTTYPE="INVALIDATION"/>
<LISTEN IPADDR="ANY" PORT="9402" 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/Jul/2005:19:27:04 +0000] [notification 9612] [ecid: -] OracleAS Web Cache 10g (10.1.2)
[25/Jul/2005:19:27:04 +0000] [notification 9403] [ecid: -] Maximum number of file/socket descriptors set to 950.
[25/Jul/2005:19:27:04 +0000] [notification 13002] [ecid: -] Maximum allowed incoming connections are 700
[25/Jul/2005:19:27:04 +0000] [alert 13305] [ecid: -] Failed to assign port 80: Permission denied
[25/Jul/2005:19:27:04 +0000] [alert 9707] [ecid: -] Failed to start the server.
[25/Jul/2005:19:27:04 +0000] [alert 9609] [ecid: -] The server process could not initialize.
[25/Jul/2005:19:27:04 +0000] [notification 9610] [ecid: -] The server is exiting.
Solution 4
See: "Running webcached with Root Privilege" for instructions on configuring thewebcached executable to run as root.
|
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/Jul/2005:19:30:48 +0000] [notification 9612] [ecid: -] OracleAS Web Cache 10g (10.1.2)
[25/Jul/2005:19:30:48 +0000] [alert 9604] [ecid: -] Could not increase the number of file/socket descriptors to 2250.
[25/Jul/2005:19:30:48 +0000] [alert 9707] [ecid: -] Failed to start the server.
Solution 5
See Also:
|
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/Jul/2005:19:35:00 +0000] [warning 11917] [ecid: -] SSL wallet wallet file /etc/ORACLE/WALLETS/janedoe/ewallet.p12 does not exist [25/Jul/2005: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/Jul/2005:19:35:00 +0000] [warning 11922] [ecid: -] Wallet wallet fails to open at location /etc/ORACLE/WALLETS/janedoe, NZERROR 28759, as user janedoe [25/Jul/2005:19:35:00 +0000] [alert 9609] [ecid: -] The server process could not initialize. [25/Jul/2005:19:35:00 +0000] [notification 9610] [ecid: -] The server is exiting.
Solution 6
To resolve this error, perform the following procedure:
Ensure that the wallet directory exists:
/etc/ORACLE/WALLETS/
user_name
on UNIX
%USERPROFILE%\ORACLE\WALLETS
on Windows
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.
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.
Restart OracleAS Web Cache with the following command:
opmnctl restartproc ias-component=WebCache
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
Set the ORACLE_HOME
environment variable.
Go to the $ORACLE_HOME/webcache/lib
directory.
Run the following command to relink the library
make -f ins_calypso.mk install
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 thewebcached 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 thesetidentity 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.
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. 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.
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
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).
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: "How OracleAS Web Cache Can Cache Dynamically Generated Content" for an overview of invalidation propagation |
This section describes workarounds to invalidation timeouts:
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/Jul/2005: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/Jul/2005: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:
On the central or provider cache, use a text editor to open the webcache.xml
file.
Locate the CALYPSONETINFO
element:
<CALYPSONETINFO...INV_PEER_TIMEOUT="300" INV_GLOBAL_TIMEOUT="300".../>
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.
Save webcache.xml
.
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:
On cache cluster members, use a text editor to open the webcache.xml
file.
Locate the CALYPSONETINFO
element:
<CALYPSONETINFO...INV_PEER_TIMEOUT="300" INV_GLOBAL_TIMEOUT="300".../>
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.
Save webcache.xml
.
Restart OracleAS Web Cache with the following command:
opmnctl restartproc ias-component=WebCache
Propagate changes to all cache cluster members and restart the other cache cluster members.
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.
Evaluate the caching rules to determine if additional content can be cached.
The client 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 client 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.
Client 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 client requests
The network connection keep-alive timeout is set a value more than 0.
See Also:
|
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 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:
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).
See Also: "Configuring End-User Performance Monitoring" for further information about 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:
Check that the End-User Performance Monitoring Format is configured as the logging format for the site.
Ensure end-user performance monitoring is configured for the site.
Check the site-to-server mappings.
OracleAS Web Cache fails to bind a session to an origin server in a configuration that uses OracleAS Forms Services.
Problem
The mechanism for session binding is not set for OC4J-based applications. In releases prior to 10g Release 2 (10.1.2), OracleAS Web Cache used an internal tracking mechanism that was not suitable for OracleAS Forms Services.
Solution
Configure the OCJ4-based session binding mechanism:
Upgrade to OracleAS Web Cache 10g Release 2 (10.1.2).
Reconfigure session binding, making sure to select the OC4J-based mechanism.
For all sites enabled for end-user performance monitoring, ensure that all possible host names and associated port numbers used to access the site are specified either in the specification of the site, or as one of the aliases of the site. If a site is accessed using a host name and port that is not defined, end-user performance monitoring is not instrumented for the site.
See Also:
|
Common configuration mistakes include:
Not mapping sites correctly to origin servers from the Sites page of Application Server Control Console (Web Cache Home page > Administration tab > Properties > Application > Sites) or the Site-to-Server Mapping page of OracleAS Web Cache Manager (Origin Servers, Sites, and Load Balancing > Site-to-Server Mapping).
When sites are not mapped, OracleAS Web Cache directs requests to the default Oracle HTTP Server. Browsers may receive an HTTP 500
error code.
Other site configuration errors include:
Not specifying all the site aliases
Misuse of the wildcard character *
Creating multiple site-to-server mappings for a site with multiple origin servers
When configuring the Ping URL field 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), how you enter the URL depends on the origin server. For an application Web Server, enter either a relative or fully-qualified URL that includes the domain name, or site name, representing the virtual host of the application Web server. For a proxy server, enter a fully-qualified URL that includes the domain name, or site name, representing the virtual host of the origin server behind the proxy server. Ensure the URL is cached.
Running webcached
with root privilege
You must configure webcached
to run with root privilege when privileged port numbers less than 1024, there are more than 1,024 file descriptors, or the current opmnctl
or webcachectl
user does not match the configured user in the Security page of Application Server Control Console (Web Cache Home page > Administration tab > Properties > Web Cache > Security) or the Process Identity page of OracleAS Web Cache Manager (Properties > Process Identity) of OracleAS Web Cache Manager.
To diagnose if caching rules are set up to serve wrong or outdated content:
Determine the contents of the cache by:
Listing the most popular requests, either cached or not cached requests, along with the caching rules associated with cached objects
Instead of listing the default value of 100, expand the list to see if your object is cached.
Listing the contents of the cache
Previewing invalidation without invalidating actual content
See Also:
|
Enable event logging with a logging level of TRACE. Then, resubmit the request.
Trace level logging shows whether an object is cached and which caching rule it matches.
Compare the contents of the cache to the caching rules to determine discrepancies or syntax errors.
Adjust caching rules by adding or removing rules, adjusting expression type syntax, or changing the precedence of rules.
Enable access logging. Then, send an explicit request for the object
By analyzing the access log determine, you can determine if OracleAS Web Cache is serving the object from its cache or is forwarding the request to the origin server.
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. It is also useful to display the diagnostic information and event log information in the HTML response body.
In addition, developers using Oracle JDeveloper can use the ESI Servlet Filter extension to run and debug ESI or JESI JSPs.
See Also:
|
The following topics describe using the event log and HTML response body to diagnose template and fragment syntax errors:
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/Jul/2005: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/Jul/2005:16:02:12 -0500] [error 12086] [ecid: 25732665668,0] ESI syntax error. Unrecognized keyword exclude is at line 2.
[24/Jul/2005: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
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/Jul/2005: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/Jul/2005:16:10:40 -0500] [error 12086] [ecid: 25733186204,0] ESI syntax error. Unrecognized keyword exclude is at line 2.
[24/Jul/2005: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/Jul/2005: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/Jul/2005: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/Jul/2005:16:10:40 -0500] [error 11368] [ecid: 25733186204,0] ESI exception error response is returned.
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/Jul/2005: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/Jul/2005:16:14:41 -0500] [error 12086] [ecid: 25733432444,0] ESI syntax error. Unrecognized keyword exclude is at line 2.
[24/Jul/2005: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/Jul/2005: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/Jul/2005: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/Jul/2005:16:17:23 -0500] [error 12086] [ecid: 25733598670,0] ESI syntax error. Unrecognized keyword exclude is at line 2. [24/Jul/2005: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/Jul/2005: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.
When OracleAS Web Cache is added to an existing application Web server environment, HTTP traffic changes effect the following aspects of the application:
Protocol/Hostname/Port Mapping
To ensure traffic is directed through OracleAS Web Cache, configure all absolute URLs to use the protocol, host name, and port number of OracleAS Web Cache. Also, ensure the Port
directive in the Oracle HTTP Server httpd.conf
file specifies the OracleAS Web Cache listening port.
SSL Processing
Add certificate management to OracleAS Web Cache, if the connection between the client and OracleAS Web Cache is HTTPS, but the connection between OracleAS Web Cache and the origin server is HTTP.
Page Delivery Timing
For compressed pages or pages that requires processing, OracleAS Web Cache waits for an entire page from the origin server before it sends it to the browser.
HTTP Protocol
OracleAS Web Cache transparently performs the following:
OracleAS Web Cache upgrades and downgrades the protocol version between the origin server and client.
For cacheable objects, OracleAS Web Cache sends content to clients with the Content-Length
response header instead of chunked encoding for the initial request.
For cache hits, OracleAS Web Cache overwrites the Content-Length
response-header field whenever it is different from what the origin server sent. This feature ensures browsers receive full page content.
Several SSL errors are reported with NZE errors in the event log, as listed in Chapter 17. These errors are described in full in the Oracle Database Error Messages. Because this document is not available with the Oracle Application Server documentation library, the most common NZE errors reported in the OracleAS Web Cache event log are listed here to aid with troubleshooting:
You can find more solutions on Oracle MetaLink, http://metalink.oracle.com
. If you do not find a solution for your problem, log a service request.
See Also: Oracle Application Server Release Notes, available on the Oracle Technology Network:http://www.oracle.com/technology/documentation/index.html
|