6
Advanced Oracle9iAS Portal Configuration

In the previous chapter we discussed various Oracle9iAS Portal configurations, ranging from a single machine configuration to a full scale enterprise deployment scenario, using Load Balancing routers, as well as multiple middle-tier servers and Oracle9iAS Web Cache clusters.

This chapter discusses the configuration that needs to be performed to accommodate some of these more advanced configurations. Specific topics include:

• Configuring Virtual Hosts

• Parallel Page Engine Configuration

• Configuring Reverse Proxy Servers Over the Internet

• Configuring Load Balancing Routers

• Setting up Two Sites Using the Same Infrastructure

• Configuring Multiple Middle-Tiers to Use the Same Infrastructure

• Tuning the Oracle HTTP Server

• Configuring Oracle9iAS Portal to Work with Oracle9iAS Web Cache

6.1 Configuring Virtual Hosts

The Oracle9i Application Server HTTP server supports the configuration of virtual hosts. This allows a single machine and port to represent a number of virtual hosts. To configure virtual hosts, you must set this up on both Oracle9iAS Portal as well as on the Oracle HTTP Server.

In our example, let's assume that we want to access Oracle9iAS Portal as http://www.abc.com as well as http://www.xyz.com. Also, let's assume that the Oracle9iAS Single Sign-On Server's URL is http://www.login.com.

To configure virtual hosts, open and edit the Oracle HTTP Server configuration file, httpd.conf located in ORACLE_HOME/Apache/Apache/conf. Verify that the contents of the file includes the similar information in the Virtual Hosts section:

### Section 3: Virtual Hosts
NameVirtualHost 127.0.0.1

<VirtualHost 127.0.0.1>
    ServerName www.abc.com
</VirtualHost>

<VirtualHost 127.0.0.1>
    ServerName www.xyz.com
</VirtualHost>

<VirtualHost 127.0.0.1>
    ServerName www.login.com
</VirtualHost>

This example uses the IP address 127.0.0.1, which represents the local machine. This can be any valid IP address.

The domain names specified in the ServerName entries need to be valid domain names. If you are setting up Oracle9iAS Portal on a local laptop, make the appropriate entries in your local hosts file.

# Copyright (c) 1993-1995 Microsoft Corp.
#
# This is a sample HOSTS file used by Microsoft TCP/IP
# for Windows NT/2000.
#
127.0.0.1 localhost
127.0.0.1 www.abc.com
127.0.0.1 www.xyz.com
127.0.0.1 www.login.com

For Single Sign-On on the Oracle9iAS Single Sign-On Server to work properly, it must always be referenced by any Partner Application with the same hostname in the URL. This is because cookies are sent back only to the host that generated them. So, in the preceding example, the Oracle9iAS Single Sign-On Server must always be referenced as http://www.login.com. Thus, you must register www.abc.com, www.xyz.com, and www.login.com as Partner Applications:

1. Add a Partner Application entry for www.abc.com.

2. Add a Partner Application for www.xyz.com.

3. Add a Partner Application for the Oracle9iAS Single Sign-On Server, www.login.com, by running the Oracle9iAS Portal Configuration Assistant Configuration Assistant in the SSOPARTNERCONFIG mode.

   See also: Section 3.2.4, "SSOPARTNERCONFIG OPCA Mode" for SSOPARTNERCONFIG mode usage information.

6.2 Parallel Page Engine Configuration

The Oracle9iAS Portal architecture is designed around a three-tier architecture that allows any browser to connect to it. This flexible architecture allows each component (browser, Oracle HTTP Server listener, Oracle9i database, and Oracle9iAS Portal) to be upgraded individually as required.

6.2.1 Configuring Parallel Page Engine Parameters

When a page is requested from Oracle9iAS Portal, the request is made from the browser to the Oracle HTTP Server listener. The returned page is comprised of many types of portlets. A portlet is an area on a portal page that contains data from a particular data source.

The Parallel Page Engine obtains the page metadata from the Oracle9iAS Portal Repository and is responsible for assembling the portlets on the page.

6.2.1.1 Setting PPE Configuration Parameters

With the release of Oracle9i Application Server version 9.0.2 and above, all of the servlets are installed under OC4J, based upon the application deployment. All of the configuration parameters for PPE are entered in the web.xml file related to the PPE Deployment. In the default installation, this file can be found at the following location:

$IASHOME/j2ee/home/applications/portal/portal/WEB_INF/

6.2.1.2 Parallel Page Engine Configuration Settings

The following table describes each of the different configuration parameters available for use with the Parallel Page Engine (PPE). Each parameter affects the operation of the PPE in a different manner. Some are simply for logging, while others can affect the performance of the engine, or Oracle9iAS Portal itself. In most cases, the default values should be sufficient for use, however there may be configurations where this is not the case. Each parameter is described with it's syntax, description, and default

Table 6-1 Parallel Page Engine (PPE) parameters

<init-param>
<param-name>logmode</param-name> 
<param-value>debug</param-value>
</init-param>

<init-param> 
<param-name>poolSize</param-name>
<param-value>25</param-value>
</init-param>

<init-param> 
<param-name>requesttime</param-name>
<param-value>30</param-value>
</init-param>

<init-param> 
<param-name>minTimeout</param-name>
<param-value>5</param-value>
</init-param>

<init-param>
<param-name>stall</param-name>
<param-value>120</param-value>
</init-param>

<init-param>
<param-name>httpsports</param-name> 
<param-value>433:444</param-value>
</init-param>

<init-param>
<param-name>prefix</param-name>
<param-value>/pls</param-value>
</init-param>

<init-param>
<param-name>proxyHost</param-name>
<param-value>ph.comp.com</param-value>
</init-param>
<init-param>
<param-name>proxyPort</param-name>
<param-value>8888</param-value>
</init-param>

<init-param>
<param-name>offlinePath</param-name>
<param-value>/path/offline.html</param-val
ue>
</init-param>
<init-param>
<param-name>offlinePathMxml</param-name>
<param-value>/path/offline.xml</param-valu
e>
</init-param>

<init-param>
<param-name>showError</param-name>
<param-value>true</param-value>
</init-param>

<init-param>
<param-name>cacheBuffer</param-name>
<param-value>32768</param-value>
</init-param>

<init-param>
<param-name>cacheEncryptionKey</param-name
>
<param-value>KEY</param-value>
</init-param>

<init-param>
<param-name>showPageDebug</param-name>
<param-value>false</param-value>
</init-param>

<init-param>
<param-name>dmsLogging</param-name>
<param-value>false</param-value>
</init-param>

<init-param>
<param-name>queueTimeout</param-name>
<param-value>10</param-value>
</init-param>

<init-param>
<param-name>cacheDir</param-name>
<param-value>/PATH/</param-value>
</init-param>

<init-param>
<param-name>jspRoot</param-name>
<param-value>/JSP PATH/</param-value>
</init-param>

<init-param>
<param-name>jspSrcAlias</param-name>
<param-value></param-value>
</init-param>

6.3 Configuring Reverse Proxy Servers Over the Internet

A reverse proxy server is a host process which is used as part of a firewall architecture to isolate the internal hosts from the externally accessible host(s) by providing a proxy through which external requests must pass to access internal services. Typically, such a proxy server takes the form of a dual-homed host. This means that it is a host with two network interface cards. One interface connects to the external network, and the other interface connects to the internal network, or demilitarized zone (DMZ) of the firewall.

Figure 6-1 Internet configuration with reverse proxy server

Text description of the illustration proxy.gif

In this architecture, the browser accesses the server through a hostname which is published by the proxy server. The proxy server then forwards the request to the actual host within the firewall, which could be some other host name.

For this example, let's assume the following:

• The published address is www.myportal.com

• Internal to the firewall, the server name for the Oracle9i Application Server middle-tier is actually server.company.com.

• Externally, the server is addressed with the default port 80; however, internally, the server.company.com is listening on port 7777.

Complete these steps to configure Oracle9iAS Portal for this architecture:

1. Define configuration settings that allow the Oracle9i Application Server middle-tier to listen on port 7777, but assert to the server that it is using port 80.

2. Create VirtualHost entries that accept the internal host name, but then assert the externally visible host name, using the ServerName directive, so that self-referential URLs rendered on the Oracle9iAS Portal pages are valid for the browser.

3. Edit the hosts file on the internal middle-tier servers to define the IP addresses for the ServerNames asserted above, so that they can resolve the hostnames that are generated by Oracle9iAS Portal, for HTTP calls looping back to fetch portlet content.

4. Run the Oracle9iAS Portal Configuration Assistant (OPCA) in the MIDTIER mode to associate the reverse proxy server with Oracle9iAS Portal. Specify the following values:
   • -host reverse_proxy_hostname

   • -port reverse_proxy_port

   • -chost web_cache_host

   • -cport_i web_cache_invalidation_port

   Oracle9iAS Web Cache invalidation messages will now be sent to the Oracle9iAS Web Cache invalidation port. Note that the use of Oracle9iAS Web Cache is not depicted in the graphic that accompanies this example.

   See also: Section 3.2.2, "MIDTIER OPCA Mode" for more information on the OPCA MIDTIER mode.

5. Register the www.myportal.com domain name on a domain name server on the Internet, with IP address 196.12.67.8.

   Note: The IP addresses used in this example are for illustration purposes only and may not be valid IP addresses.

The following figure shows the server names and ports used in the preceding example:

Figure 6-2 Example of reverse proxy server configuration

Text description of the illustration proxyeg.gif

6.3.1 Configuring the Oracle HTTP Server

You provide directives in the Oracle HTTP Server configuration file, httpd.conf, which specify the behavior described in the points above. The reverse proxy server contacts the internal middle-tier server as server.company.com over port 7777.

When the Oracle HTTP Server invokes the mod_plsql, and mod_jserv, it then passes www.myportal.com as the ServerName and port 80. URLs that are generated by Oracle9iAS Portal code use www.myportal.com and port 80.

The directive "useCanonicalName on" instructs Oracle HTTP Server to use the ServerName specified. Otherwise, it passes the name used in the Host field of the request.

The relevant sections in the httpd.conf file for the server.company.com Oracle9i Application Server configuration are shown in the following.

### Section 2: 'Main' server configuration
...
Port 80
Listen 7777
Listen 80

ServerName www.myportal.com
...
UseCanonicalName On
...
### Section 3: Virtual Hosts
#
# VirtualHost: If you want to maintain multiple domains/hostnames on 
# your machine you can setup VirtualHost containers for them.
#
# If you want to use name-based virtual hosts you need to define at
# least one IP address (and port number) for them.
#

# This section is mandatory for URLs that are generated by
# the PL/SQL packages of the Oracle Portal
# These entries dictate that the server should listen on port
# 7777, but will assert that it is using port 80, so that
# self-referential URLs generated specify www.myportal.com:80
# This will create URLs that are valid for the browser since
# the browser does not directly see the host server.company.com.
NameVirtualHost 123.45.67.8:7777

<VirtualHost server.company.com:7777>
ServerName www.myportal.com
Port 80
</VirtualHost>

# Since the previous virtual host entry will cause all links 
# generated by the Oracle Portal to use port 80, the server.company.com
# server needs to listen on 80 as well since the Parallel Page
# Engine will make connection requests to Port 80 to request the
# portlets.

NameVirtualHost 123.45.67.8:80

<VirtualHost server.company.com:80>
ServerName www.myportal.com
Port 80
</VirtualHost>

If you need to support multiple aliases for the published address www.myportal.com, then some additional directives are needed. For example, if the server also needs to be accessible as www.portal.com, then you need to define additional virtual host entries on the internal server. This is so the reverse proxy directs requests from each corresponding published hostname to a related internal host alias which can assert the correct published name.

In this example, the VirtualHost sections appear as follows:

NameVirtualHost 123.45.67.8:7777

<VirtualHost server.company.com:7777>
ServerName www.myportal.com
Port 80
</VirtualHost>

<VirtualHost server2.company.com:7777>
ServerName www.portal.com
Port 80
</VirtualHost>

NameVirtualHost 123.45.67.8:80

<VirtualHost server.company.com:80>
ServerName www.myportal.com
Port 80
</VirtualHost>

<VirtualHost server2.company.com:80>
ServerName www.portal.com
Port 80
</VirtualHost>

6.3.2 Resolving Domain Names

A local HOSTS file can help resolve domain names that are not normally visible to the internal network. For example, the Oracle9i Application Server host for server.company.com makes requests to itself, but the URLs that it is requesting are referring to www.myportal.com. You must create host entries in the local HOSTS file on that machine allowing it to resolve this name, within the firewall. The hosts entry for this example should include the following lines:

# This is a sample HOSTS file used by Microsoft TCP/IP
# for Windows NT/2000.
#
127.0.0.1    localhost
123.45.67.8  www.myportal.com

If you do not provide these entries in the local HOSTS file, then you need to set the Oracle9i Application Server host to recognize a proxy server that would take the request out to the Internet and back in through the reverse proxy (www.myportal.com). Avoid this setup as this may result in poor performance.

6.4 Configuring Load Balancing Routers

The purpose of a Load Balancing Router (LBR) is to provide a single published address to the client browsers, and provide a "farm" of Web servers which actually service the requests, based on the distribution of the requests done by the LBR. The LBR itself is a very fast network device which can distribute Web requests to a large number of physical servers.

If you want to install multiple Oracle9i Application Server middle-tier servers to handle a large load, you could configure Oracle9iAS Portal as illustrated in the following diagram:

Figure 6-3 Load balancing router configuration

Text description of the illustration load.gif

This example shows that the Load Balancing Router (LBR) balances the load between all three instances of the Oracle9iAS Web Cache cluster. each one of the Oracle9iAS Web Cache clusters can in turn load balance any of the middle-tier servers which communicate with Oracle9iAS Single Sign-On Server and Oracle9iAS Portal. In this example, let's call the three Oracle9iAS Web Cache instances wc1, wc2, and wc3, and let's call the Oracle9i Application Server middle-tier servers svr1, svr2, and svr3. So in the above example wc1 can load balance svr1, svr2, as well a svr3. Additionally wc2 and wc3 can do the same.

All the Oracle9i Application Server middle-tier servers must have DAD entries for each of the databases. A good way to accomplish this is to have the middle-tier servers share a file system that contains the configuration information for the DADs, and allows them to share cache files.

The important points to consider with this configuration include:

• The Internet DNS maps the name www.myportal.com to the external IP address on the LBR.

• The LBR performs load balancing of requests to www.myportal.com to svr1.company.com, svr2.company.com, and svr3.company.com, addressing the request to their IP addresses, but still containing www.myportal.com in the Host: field of the HTTP request.

• Each of the middle-tier hosts accepts requests to www.myportal.com, and their httpd.conf files assert that name as the ServerName. Hence the names svr1, svr2, and so on are irrelevant.

• Unless your LBR does port mapping, you should configure the internal servers to use the same ports as the LBR.

• Optimal cache utilization can be realized by mounting a shared file system on which to write the cache files. If you decide not to have the middle-tier servers share a cache directory, caching will still work, but with a lower hit ratio

6.4.1 Additional Configuration Related to Oracle9iAS Web Cache Invalidation

Some additional configuration is needed, because invalidation requests need to be returned properly to Oracle9iAS Web Cache and not to the LBR.

If the LBR that is in use can listen on multiple ports and if it also has the ability to route the invalidation messages back to Oracle9iAS Web Cache, then OPCA needs to be run in the MIDTIER mode, specifying the following settings:

• -host LBR host name

• -port LBR port name

• -chost LBR host name

• -cport_i LBR port name

If the LBR is not able to listen on multiple ports, or if it does not have the ability to route the invalidation messages back to Oracle9iAS Web Cache, another LBR, which we will call the invalidation request handling LBR, needs to be set up to handle the routing of the invalidation messages. In this case, OPCA needs to be run in the MIDTIER mode, specifying the following settings:

• -host LBR host name

• -port LBR port name

• -chost invalidation request handling LBR host name

• -cport_i invalidation request handling LBR port name

Instead of using another LBR as an invalidation request handling LBR, you could also use one of the Oracle9iAS Web Cache instances, in the Oracle9iAS Web Cache cluster to handle the invalidation (for example wc1). This instance must be part of the Oracle9iAS Web Cache cluster, but it is recommended that you do not cache anything, or handle HTTP requests with this designated Oracle9iAS Web Cache instance, in order to increase availability. In this case, OPCA needs to be run in the MIDTIER mode, specifying the following specific settings:

• -host LBR host name

• -port LBR port name

• -chost hostname of the designated Oracle9iAS Web Cache cluster instance.

• -cport_i invalidation port of the designated Oracle9iAS Web Cache cluster instance

Once one of the above options is configured correctly, the invalidation messages will be routed correctly back to Oracle9iAS Web Cache and the benefits from using the LBR, as well as Oracle9iAS Web Cache can be enjoyed.

6.5 Setting up Two Sites Using the Same Infrastructure

If you want to configure two sites to use the same Portal repository, some additional Oracle9iAS Web Cache configuration is required.

Assuming that you would want to add another site called www.myportal2.com to the configuration shown in Figure 6-3, "Load balancing router configuration". www.myportal2.com needs to be mapped to the same LBR.

Assuming that you have already defined www.myportal.com as a site in Oracle9iAS Web Cache, the additional configuration consists of creating a site alias in Oracle9iAS Web Cache.

It is important that www.myportal.com is set up as a site, while www.myportal2.com has to be defined as a site alias. This way, the invalidation messages sent to Oracle9iAS Web Cache invalidate content that is cached against both sites. This configuration makes the multiple site definitions transparent to the Portal repository.

6.6 Configuring Multiple Middle-Tiers to Use the Same Infrastructure

Multiple Oracle9iAS Portal middle-tier installations associated to a single Oracle9i Application Server infrastructure do not work properly in a default Oracle9i Application Server installation. There are a number of integration points that need to be addressed in case you try to use such a configuration:

Oracle9iAS Portal and Oracle9iAS Web Cache

Detailed steps for setting up Oracle9iAS Web Cache in a multiple middle-tier environment are described in Section 6.8.8, "Associating Multiple Middle-Tiers to a Single Infrastructure".

Oracle9iAS Portal and OID

Every Oracle9iAS Portal middle-tier installation drops and recreates the Portal users in OID. This means that the Oracle9i Application Server instance password of the last run middle-tier installation should be used for Portal runtime access.

After all the middle-tier installations are performed, the users can change the Portal user password in OID. This does not require any other changes in the Portal repository.

Oracle9iAS Portal and Oracle9iAS Wireless

If Oracle9iAS Wireless is configured with Oracle9iAS Portal during the middle-tier installation, the middle-tier install registers the Portal on the Oracle9iAS Wireless service. In case of multiple midtier installs, the last configured Oracle9iAS Wireless service URL is stored in the Oracle9iAS Portal instance. You can change this to your choice of Oracle9iAS Wireless service by running the following scripts in the Oracle9i Application Server middle-tier selected for the Oracle9iAS Wireless service:

UNIX:

ORACLE_HOME/wireless/sample/portalRegistrar.sh 

Windows:

ORACLE_HOME/wireless/sample/portalRegistrar.bat

Portal Provider UI Framework

Multiple Portal middle-tier installations will overwrite the existing Default JPDK Instance URL which is used for creating the Providers. The users can change this to their choice of JPDK Instance URL using the following steps :

1. Login to Portal in the browser.

2. Click on the Builder link.

3. Click on the Administrator tab. Click on Global Settings in the Services portlet.

4. Click on the Configuration tab. Enter the Default JPDK Instance URL of any installed Portal middle-tier.

6.7 Tuning the Oracle HTTP Server

However you choose to configure the Oracle HTTP Server listener, you can optimize performance by setting an approximate number of simultaneous requests that can be handled by the Oracle HTTP Server listener.

On UNIX, in particular, since the Oracle HTTP Server is process-based, each process needs to open a database connection for each DAD that has requested it. As a result, the number of requests can be quite high, which may result in clients being "locked out" if the number of sessions allowable has been exceeded. However, setting too high of a value unnecessarily consumes resources.

The scenario is described below:

1. For every service request from an Oracle9iAS Portal DAD, there is one network connection and two sessions (the two sessions use the same physical connection).

   The first session is for "portal" and the second is for "portal_public".

2. If you are logging into Oracle9iAS Portal, then you'll need to open a connection for the Oracle9iAS Single Sign-On Server DAD (SSO DAD). This will consume one network connection and two sessions.

   In this case, the first session is for "orasso" and the second session is for "ora_sso_public".

3. The Oracle HTTP Server configuration setting that determines the maximum number of requests being handled simultaneously is named MaxClients. It defaults to 150.

   If each user were logging in and working in Oracle9iAS Portal, then scenario (1) and (2) above would result in four sessions per process. The total number of sessions for such a scenario is calculated as follows:

   150 * 4 = 600 
   
   

   600 sessions and approximately 300 database connections (2 sessions per connection)

6.7.1 Configuring the MaxClient Setting

Since login frequency is generally lower than Oracle9iAS Portal access frequency, it makes sense to configure the Oracle9iAS Single Sign-On Server on a separate Oracle HTTP Server listener. The objective is to tune down the MaxClient setting to a value that is reasonable without affecting the needs of the portal system.

Oracle9iAS Portal makes extensive use of mod_plsql which maintains a pool of connections to the database. The MaxClient parameter tunes the number of processes which directly relates to the number of database connections pooled by mod_plsql.

Follow these steps to configure the MaxClient setting:

1. For the Oracle9iAS Single Sign-On Server's listener, once you've determined the approximate value to set for the MaxClients parameter, edit this accordingly in the configuration file, httpd.conf, which is located in:

   ORACLE_HOME/Apache/Apache/conf/
   
   

   Tune down the MaxClients setting to control the number of requests that Oracle HTTP Server services on the Oracle HTTP Server listener. This ultimately controls the maximum number of sessions that could be established.

2. For the Oracle9iAS Portal listener, you can separately tune the MaxClients parameter according to the needs of the Oracle9iAS Single Sign-On Server and the needs of Oracle9iAS Portal, without affecting each other. This parameter directly corresponds to the number of sessions established and to the maximum workload that the Oracle HTTP Server listener can handle on the Portal listener.

   The MaxClients section in the httpd.conf file is shown below:

   # Limit on total number of servers running, i.e., limit on the number
   # of clients who can simultaneously connect --- if this limit is ever
   # reached, clients will be LOCKED OUT, so it should NOT BE SET TOO LOW.
   # It is intended mainly as a brake to keep a runaway server from taking
   # the system with it as it spirals down...
   #
   MaxClients 150
   
   

   Note: If you tune separately, you will have a separate listener for Oracle9iAS Portal and the Oracle9iAS Single Sign-On Server. The former controlling the resources (sessions) on the portal database and the latter controlling the resources on the Oracle9iAS Single Sign-On Server database. The number of sessions and connections that the database permits is limited by the value set in the Oracle9i database's init.ora. Refer to the Oracle9i database documentation library for more information.

6.8 Configuring Oracle9iAS Portal to Work with Oracle9iAS Web Cache

This section will discuss how to configure Oracle9iAS Portal to work with Oracle9iAS Web Cache. This section includes the following subsections:

• Evaluating the Oracle9iAS Web Cache Logs

• Oracle9iAS Web Cache Configuration Scripts

• Troubleshooting the Oracle9iAS Web Cache Configuration

• Accessing the Oracle9iAS Web Cache Administration Portlet

• Tuning Oracle9iAS Web Cache

• Disabling Oracle9iAS Web Cache

• Shutting down Oracle9iAS Web Cache completely

• Associating Multiple Middle-Tiers to a Single Infrastructure

  See also: Oracle9iAS Web Cache Administration and Deployment Guide in the Oracle9i Application Server documentation library.

6.8.1 Evaluating the Oracle9iAS Web Cache Logs

Log files for Oracle9iAS Web Cache are typically stored in ORACLE_HOME/webcache/logs on UNIX and ORACLE_HOME\webcache\logs on Windows.

There are two log files:

• The access_log file.

• The event_log file.

  See also: Oracle9iAS Web Cache Administration and Deployment Guide in the Oracle9i Application Server documentation library.

6.8.2 Oracle9iAS Web Cache Configuration Scripts

You can configure Oracle9iAS Portal to work with Oracle9iAS Web Cache in a variety of ways, but some scripts are supplied to facilitate this. These scripts are covered in more detail in Section B.2, "Oracle9iAS Web Cache configuration scripts".

The scripts covered in Appendix B are:

• cachseed.sql, which allows you to modify all the Oracle9iAS Web Cache configuration parameters.

• cachset.sql, which allows you to turn the use of Oracle9iAS Web Cache on or off. Information on how to disable Oracle9iAS Web Cache completely is covered as well.

• cachjsub.sql, which allows you to manage the invalidation message processing job.

6.8.3 Troubleshooting the Oracle9iAS Web Cache Configuration

6.8.4 Accessing the Oracle9iAS Web Cache Administration Portlet

You can access the Oracle9iAS Web Cache administration portlet directly from Oracle9iAS Portal. In the Services portlet, go to the Proxy Settings page. By default, the Services portlet is located on the Oracle9iAS Portal home page's Administer tab as shown in the following image.

Figure 6-4 The Oracle9iAS Web Cache administration portlet

Text description of the illustration cg_wcadm.gif

After entering the Oracle9iAS Web Cache administrator username and password, you will be able to use the web-based Oracle9iAS Web Cache administration tool, as shown in the image below.

Figure 6-5 The Oracle9iAS Web Cache administration tool

Text description of the illustration cg_wchme.gif

6.8.5 Tuning Oracle9iAS Web Cache

6.8.6 Disabling Oracle9iAS Web Cache

Follow these steps if you want to disable the use of Oracle9iAS Web Cache:

1. In the Services portlet, click on Global Settings. By default, the Services portlet is located on the Oracle9iAS Portal home page's Administer tab.

2. Click on the Cache tab.

3. Uncheck the "Enable Web Cache for caching portal content" check box.

   Note: By doing this, you effectively stop using Oracle9iAS Web Cache in Oracle9iAS Portal. However, requests to and from the middle-tier will still pass through Oracle9iAS Web Cache. If you are concerned about the performance loss that is caused by this extra step, you can also shut down Oracle9iAS Web Cache completely as shown in Section 6.8.7, "Shutting down Oracle9iAS Web Cache completely".

6.8.7 Shutting down Oracle9iAS Web Cache completely

If you want to shut down Oracle9iAS Web Cache completely, you must perform the following steps:

1. Run cachset.sql as mentioned in Section B.2.2, "Using cachset.sql".

2. Shut down the Oracle9iAS Web Cache instance.

   See also: Oracle9iAS Web Cache Administration and Deployment Guide in the Oracle9i Application Server documentation library for information about shutting down Oracle9iAS Web Cache.

1. Open the httpd.conf file and change the Listen directive to the port on which Oracle9iAS Web Cache was listening. this file is located in:

   ORACLE_HOME/Apache/Apache/conf/
   
   

2. Restart the Oracle HTTP Server.

   See also: Oracle9i Application Server Administrator's Guide in the Oracle9i Application Server documentation library for information about shutting down the Oracle HTTP Server.

6.8.8 Associating Multiple Middle-Tiers to a Single Infrastructure

Multiple Oracle9iAS Portal middle-tier installations associated to a single Oracle9i Application Server infrastructure do not work properly in a default Oracle9i Application Server installation. The reason for this is that Oracle9iAS Portal sends invalidation messages to a single Oracle9iAS Web Cache instance. Entries for the location of the Oracle9iAS Web Cache host, the invalidation and administrator port are stored within the Oracle9iAS Portal instance. Every Portal middle-tier installation (performed with the Oracle9iAS Portal Configuration Assistant (OPCA) in MIDTIER mode) overwrites these entries. This means that only the last installed portal middle-tier will work properly, because invalidation messages for the previous installation are now sent to the wrong Oracle9iAS Web Cache. This can result in stale content, as the content in the previously installed middle-tier will never get invalidated properly.

The following image shows this scenario:

Figure 6-6 Multiple Middle-Tiers Associated to a Single Infrastructure

Text description of the illustration cg_mltmt.gif

When the OPCA is run in MIDTIER mode on Svr2, everything is set up to work fine. If after that, however, the OPCA is run in MIDTIER mode for Svr1, the settings that were previously stored for Svr2 in Oracle9iAS Portal are overwritten.

There are two ways to address this issue:

1. Disable the use of Oracle9iAS Web Cache in Oracle9iAS Portal.

   You can disable Oracle9iAS Web Cache from within Oracle9iAS Portal by following the steps explained in Section 6.8.6, "Disabling Oracle9iAS Web Cache".

   Alternatively, if you are unable to login through Svr2 into the Portal due to this misconfiguration, you can run cachset.sql script to disable the use of Oracle9iAS Web Cache in the Portal, as described in Section B.2.2, "Using cachset.sql".

   Note: Do not forget to clear the File System Cache after disabling the use of Oracle9iAS Web Cache, in order to make sure that the served content is up-to-date.

2. Shut down Oracle9iAS Web Cache on one of the middle-tiers.

   Choosing this option will allow you to still use Oracle9iAS Web Cache on one of the middle-tiers, taking at least partial advantage of the benefits that Oracle9iAS Web Cache has to offer.

   In the example shown, you could, for example, shut down Oracle9iAS Web Cache on Svr2. This is better than disabling the use of Oracle9iAS Web Cache, because it allows invalidation messages to still be sent to Svr1. Follow the instructions in Section 6.8.7, "Shutting down Oracle9iAS Web Cache completely" to shut down one of the Oracle9iAS Web Cache instances.