Possible to use Web Cache to map sites to URL?

We've just installed Collaboration Suite 10g. We'd like to setup public URL's to point to different components of OCS. I've already configured our public URL's to point to the OCS Application Server, but I want to take it one step further and configure them to map directly to the specific component.
Examples (Current Behavior):
http://meeting.company.com:7778 maps to http://ocs.company.local:7778
The behavior I want is:
http://meeting.company.com:7778 mapped to http://ocs.company.local:7778/imtapp/app/prelogin.uix
Is this possible?

This should be possible:
http://download-uk.oracle.com/docs/cd/B14099_17/caching.1012/b14046/intro.htm#i1041096
You can also do it at HTTP Server level (redirect or rewrite) or with an index.html file that redirects the user.

Similar Messages

Is it possible to enable Web Cache gzip compression for 9iAS Disco Viewer?

Hi,
Sorry for repeating this question. But it's very urgent and we don't have any idea yet how to solve / work around it:
To keep it short: Is it possible to use Web Cache gzip compression for pages rendered by 9iAS Discoverer Viewer???
Our scenario: We have some Discoverer Worksheets which we want to access by ISDN dial in (64 kbit/sec). An average page needs 2 minutes only for sending the html/javascript output rendered by Disco Viewer to the client browser.
To speed up the response time when users use this slow connection, we want to activate Web Cache gzip compression.
The problem: But even when we enable Web Cache for Discoverer (configuration.xml and Web Cache rules), Web Cache doesn't compress pages generated by Discoverer Viewer. We found out that the generated responses contain the "content-disposition" HTTP-Header entry. Are we correct that this is the reason why there is no gzip compression? AND DOES ANYONE KNOW A WORKAROUND (p.e. configure Disco not to add the content-disposition http header)???
Best regards,
Matthias Scherer

Matthias,
Have you raised this as a TAR with Oracle Support? If you've got a specific question, and you need a definitive answer, raising a TAR is the best way to proceed.
regards
Mark Rittman

Is it possible to enable Web Cache gzip compression with 9iAS Disco Viewer?

Hi,
Sorry for repeating this question. But it's very urgent and we don't have any idea yet how to solve / work around it:
To keep it short: Is it possible to use Web Cache gzip compression for pages rendered by 9iAS Discoverer Viewer???
Our scenario: We have some Discoverer Worksheets which we want to access by ISDN dial in (64 kbit/sec). An average page needs 2 minutes only for sending the html/javascript output rendered by Disco Viewer to the client browser.
To speed up the response time when users use this slow connection, we want to activate Web Cache gzip compression.
The problem: But even when we enable Web Cache for Discoverer (configuration.xml and Web Cache rules), Web Cache doesn't compress pages generated by Discoverer Viewer. We found out that the generated responses contain the "content-disposition" HTTP-Header entry. Are we correct that this is the reason why there is no gzip compression? AND DOES ANYONE KNOW A WORKAROUND (p.e. configure Disco not to add the content-disposition http header)???
Best regards,
Matthias Scherer

When you set the caching rules, you can also specify whether or not you want the pages to be compressed. Web Cache compresses html pages and relies on the accept-encoding: gzip from the client header to determine whether or not to send the content compressed.

Using Web Cache to Load balance Forms Server application.

Hello,
I apologize for cross posting this question in the Forms and Caching Services forum. But I thought my question will have a better chance.
I have read that it's possible to use Oracle Web Cache as a software load balancer between multiple Application Servers.
We are running Oracle9iAS R1.0.2.2.2a, with Forms/Reports6i servers on 2 Win2k boxes i.e our Forms6i application is deployed on two seperate boxes in two distinct locations. Users at each location, use their respective App Server url.
Since the application is the same i.e. Forms6i code/fmx is the same for both locations, I am looking into loadbalancing and failover capability that Web Cache might be able to provide.
I AM ONLY LOOKING AT THE LOADBALANCING & FAILOVER capabilities and NOT caching.
So basically all users from both locations will point their browser to this Web Cache and the Web Cache will direct each connection to either of the two boxes. So, if either of the boxes dies, Web Cache will divert the requests to the other box.
My concern is whether Web Cache supports this for the Forms requests that it will receive from the users. We are using Servlet Deployment of Forms, so technically, all communication is going though the HTTPD.
Has anyone done this or has any ideas as to whether it's going to work or not? Oracle's FAQ insists that Forms is not supported. But I want to make sure that even loadbalancing is not supported. And if not supported then is there any other solution.
Any comments appreciated.
Thanks,
Manish

Using Web Cache to load balance servlet-based Forms (6i and 9i) is unofficially supported. I say "unofficially" because we have actual customers doing it and getting support, but the 2 development teams (Forms and Web Cache) haven't actually done any integration testing of this sort of configuration yet. For your case, please contact your Support rep and ask what was done to use Web Cache as a load balancer for Forms6i at METRO in Germany. The Forms product managemment team is writing up a white paper to describe how to do it, but until then, you'll need to go through Support. Please contact me if you want more information.

Need to use Web Cache without losing IP

My application needs to know the source (ip address) of requests which is tied to terminal record, but it seems Web Cache filters all the requests with its server ip address, i.e., we lose that unique ip address. Is there a set up thing I can change to keep the ip and forward the request to OHS?

We have faced with the same problem with the only exception.
Our OWA part of application resolves remote IP fine by calling owa_util.get_cgi_env('REMOTE_ADDR'), while JSP fails to resolve remote ip - ether by querying 'REMOTE_ADDR' environment, or by request.getRemoteAddr().
Our WebCache is 9.0.2.2bp2; DB - 9.2.0.2.1;

Cisco WSA : Is it possible to use web proxy in transparent mode without WCCP router ?

Hello !
I would like to use Cisco WSA as a web proxy in a transparent way (without any configuration in client's web browsers) but i don't have a WCCP router. So, is it possible ?
If yes, how to do this ?
Thank you,
Stephane Walker

Hi Stephane
The only alternative to WCCP is PBR (Policy Based Routing). With a simple configuration on the router you can redirect traffic defined as interesting by access list to WSA. On the WSA you need to configure transparent mode (Security Services -> Web Proxy -> Edit Settings -> Proxy Mode: Transparent). You also need to assure that proxy is listening on the port 80 and that HTTPS proxy is enabled (on port 443) if you want to redirect the HTTPS traffic as well.
Sample configuration for Cisco router
access-list 110 permit tcp any any eq www
route-map proxy-redirect permit 10
match ip address 110
set ip next-hop xxx.xxx.xxx.xxx
interface ethernet0/1
ip policy route-map proxy-redirect
xxx.xxx.xxx.xxx is the proxy IP in such case and access-list 110 defines web traffic (HTTP TCP/80) as interesting.
The biggest disadvantage of such solution is lack of failure detection. If the proxy will go down for some reason router will keep redirecting the traffic causing internet access outage.
Routers other than Cisco equipment should also have an option to configure policy based routing.
/Artur
Ps. It's not possible to place the WSA in-line between clients and the internet.

WMS2012: Using web limiting on a site with a redirect.

We are using Multipoint Server 2012 and have run into a situation we need assistance with. We have a website that users are required to go to and sign into. This site redirects to the login page, and then back to the original link. The only solution we have
found is to have the main link, and the redirected link as "Allowed" Users are getting confused and clicking on the redirected link on the web limiting landing page, which will not work without first coming from the main link.
Is there a way to edit this page so the users do not see the redirection link, but still allow them access to the main link and the ability to sign in?
basically in short, users go to portal.adp.com and it redirects to agateway.adp.com then back to portal.adp.com. we only want users to see the portal.adp.com link, and still allow the passthrough of the redirect.

Wait a second...there is more to that error message that I overlooked before.
There might be something other than just the way I set the CODE and CODEBASE parameters wrong here
Any ideas?
Here is the entire messsage:
load: class DisplayMonoApplet.class not found.
java.lang.ClassNotFoundException: DisplayMonoApplet.class
     at sun.applet.AppletClassLoader.findClass(Unknown Source)
     at java.lang.ClassLoader.loadClass(Unknown Source)
     at sun.applet.AppletClassLoader.loadClass(Unknown Source)
     at java.lang.ClassLoader.loadClass(Unknown Source)
     at sun.applet.AppletClassLoader.loadCode(Unknown Source)
     at sun.applet.AppletPanel.createApplet(Unknown Source)
     at sun.plugin.AppletViewer.createApplet(Unknown Source)
     at sun.applet.AppletPanel.runLoader(Unknown Source)
     at sun.applet.AppletPanel.run(Unknown Source)
     at java.lang.Thread.run(Unknown Source)
Caused by: java.io.IOException: open HTTP connection failed.
     at sun.applet.AppletClassLoader.getBytes(Unknown Source)
     at sun.applet.AppletClassLoader.access$100(Unknown Source)
     at sun.applet.AppletClassLoader$1.run(Unknown Source)
     at java.security.AccessController.doPrivileged(Native Method)
     ... 10 more

OTN Forums uses ESI and Web Cache

For the curious, the OTN Forums application uses Web Cache 9.0.2 and ESI -- I think since April.
We'll be preparing some case studies on Oracle's use of Web Cache for various customer-facing sites
over the next couple of months, so I'll be able to share more info then.

The Discoverer development team is currently making a few adjustments to Discoverer Viewer so it can work seamlessly with WebCache. You may see this functionality in 4.1.39, otherwise it will be in 9iAS release 2.
null

Can Web Cache rewrite HTTP_REFERER headers?

Can Web Cache be configured to rewrite the HTTP_REFERER header to replace the Web Cache site address:port with the dispatched application server address:port?
i.e.
If there is a Web Cache site listening on webcache.domain:80 and it is mapped to application servers: appserver1.domain:7778 and appserver2.domain:7778.
And a user requests page webcache.domain/page1, which contains a link to page2.
And then the user opens the link to page2, and Web Cache decides to send the request on to appserver2.
Can Web Cache be configured to change the HTTP_REFERER header from webcache.domain/page1 to appserver2.domain/page1?
This is important to our application, because we want to verify that our processing pages are invoked from our application validation pages (we know this method is not 100% tamper proof).
We would prefer to not have to change our application code to support Web Cache
Thanks for any info or suggestions, -Steve

Thanks Jean
I've added comments to extracts from your post.
Let's say you suddenly get a request for p2, even if
it was from the history of the browser, it would still
contain a referer header of p1, and is no different
from what it would be when the user was going through
the proper steps? Are you saying the p2 generated from
your JavaScript will have a different referer from the
p2 generated from browser history? If so, how are they
differ exactly?The browser history does not include the referer. So p2 requested from the history list does not include a referer although the original link from p1 did.
Without Web Cache, the flow is:
Step 1: a user requests appserver/page1. page1 is added to the browser history. page1 is loaded and executes JavaScript to display page2 in an iFrame. page2 is not added to the browser history (just like style sheets and other embedded requests do not get included in the history). page2 is loaded and executes JavaScript to submit an html form to load page3 into a hidden iFrame and wait for it to load. page3 is added to the browser's history becuase it was submitted; not embedded. Assuming that the request for page1 came from the browser's history, favorites, a link from an e-mail (the usual for us), or was entered manually - there will be no referer for page1. The expected referer for page2 is appserver/page1, and the expected referer for page3 is appserver/page2.
Step2: while processing page3, the application compares the server name in the requested URL (appserver/page3) with the server name from the referer URL (appserver/page2), if the servers match, page3 accesses the database and sends the requested data to the browser
Step3: JavaScript in page2 detects that page3 has loaded, interprets the results from page3, updates the content displayed by page2, and returns control to the browser user
Since this works with your app, how is webcache in
front going to break it? Note that when passing a
request
to the app server, web cache does not modify the
host header in the request.without Web Cache the browser sends requests directly to the appserver, so the request/referer entries seen by the application look like:
appserver/page1 -
appserver/page2 appserver/page1
appserver/page3 appserver/page2
with Web Cache the browser sends requests to webcache, so the request/referer entries seen by the application look like:
appserver/page1 -
appserver/page2 webcache/page1
appserver/page3 webcache/page2
This is because the Web Cache changed the request URL and did not change the referer URL.
So request to webcache.domain/abc will be sent to your
app server as is.I don't think so, doesn't the requested URL change as a result of the Web Cache mapping? i.e. webcache.domain/abc --> appserver.domain/abc
And since we do not change the referer
header, either, whatever works for your app now should
still work for you with webcache in front. This is
assuming you only do comparisons on the 2 hosts to see
if they are the same. Web Cache is changing one (request URL) of the two items (request URL and referer URL) that the application server compares.
The reason has been that we are
a cache, and in principal should be as transparent
as possible, so we try to stay away from app-sever/
apache like functionality.I support that principle 100% - from the application server perspective, it should not need to differentiate between a request directly from a browser, and a request that was issued by the cache on behalf of a browser.
The cache should completely pretend that it is the originating browser. A browser sends the request and the referer URLs. In application flow, a relationship can be inferred/required between the two URLs. Web Cache is changing one without changing the other and breaking the relationship that the application server would normally expect.
But I'm still
not convinced that you need that in webcache. :)If we want to use Web Cache in front of this application, without changing the application, then we need it. :)
Of course, we could change our application, but the more I think about the principles involved, the more I believe that it is the cache that needs changing. However, I will take another look to see if there are other standard headers related to a request that are present with and without Web Cache, and that can be used to reliably compare the server in the request URL with the server in the referer URL. If there are, then I can happily change our application so that it will work with or without Web Cache.
-Steve

IE browser and Web Cache and SSL - Internet Explorer cannot display the web page

When using IE8, IE9, or IE10 with Web Cache and SSL certain pages which display a lot of data returns the error - "Internet Explorer cannot display the web page."
if we eliminate SSL but continue to use Web Cache, the error does *not* reproduce & If we eliminate Web Cache altogether the error again does *not* reproduce. The error is only reproducible when we use SSL with Web Cache and if we use IE and we access *large* pages. The error is not reproducible with Firefox or Chrome. This is a Web Tier 11.1.1.7 installation with WebLogic 10.3.6 & Red Hat Enterprise 5 Linux x86-64
Event_log shows below errors.
[2013-06-13T16:34:35-04:00] [webcache] [NOTIFICATION:1] [WXE-09002] [logging] [ecid: ] Generated by Oracle Web Cache on Thu Jun 13 16:34:35 2013 - Build 11.1.1.7.0 130113.0721
[2013-06-13T16:34:36-04:00] [webcache] [NOTIFICATION:1] [WXE-08513] [logging] [ecid: ] Cache server process ID 4469 is starting up.
[2013-06-13T16:34:36-04:00] [webcache] [NOTIFICATION:1] [WXE-09612] [main] [ecid: ] Oracle Web Cache 11g (11.1.1.6), Build 11.1.1.7.0 130113.0721
[2013-06-13T16:34:37-04:00] [webcache] [NOTIFICATION:1] [WXE-13002] [config] [ecid: ] Maximum allowed incoming connections are 1000
[2013-06-13T16:35:00-04:00] [webcache] [NOTIFICATION:1] [WXE-09441] [stats] [ecid: ] DMS enabled
[2013-06-13T16:35:28-04:00] [webcache] [NOTIFICATION:1] [WXE-12209] [cluster] [ecid: ] A 1 node cluster successfully initialized
[2013-06-13T16:35:29-04:00] [webcache] [NOTIFICATION:1] [WXE-09614] [main] [ecid: ] The following Oracle Web Cache internal files are pre-populated to the cache: [[
        /nssb-p.adm.fit.edu:7785/_oracle_http_server_webcache_static_.html
        /nssb-p.adm.fit.edu:4448/_oracle_http_server_webcache_static_.html
[2013-06-13T16:35:29-04:00] [webcache] [NOTIFICATION:1] [WXE-09614] [main] [ecid: ] [[
The following Oracle Web Cache internal files are pre-populated to the cache: [[
        /nssb-p.adm.fit.edu:7785/_oracle_http_server_webcache_checkserviceavailability_.html
        /nssb-p.adm.fit.edu:4448/_oracle_http_server_webcache_checkserviceavailability_.html
[2013-06-13T16:35:29-04:00] [webcache] [NOTIFICATION:1] [WXE-09608] [main] [ecid: ] The cache server process started successfully.
[2013-06-13T16:35:29-04:00] [webcache] [WARNING:1] [WXE-12104] [utl] [ecid: ] Oracle Web Cache process has page faulted
[2013-06-13T16:44:22-04:00] [webcache] [ERROR:32] [WXE-11904] [security] [ecid: ] SSL handshake fails SSL-29049
[2013-06-13T16:44:22-04:00] [webcache] [WARNING:1] [WXE-11905] [security] [ecid: ] SSL additional information: The record type is unknown.
[2013-06-13T16:44:22-04:00] [webcache] [WARNING:1] [WXE-11905] [security] [ecid: ] SSL additional information: Remote IP [163.118.22.16]:55145
[2013-06-13T16:44:22-04:00] [webcache] [WARNING:1] [WXE-11905] [security] [ecid: ] SSL additional information: Local IP 163.118.170.70:4448
[2013-06-13T16:44:22-04:00] [webcache] [WARNING:1] [WXE-11906] [security] [ecid: ] SSL details: SSL error during handshake (details: internal=The record type is unknown. system=Success)
[2013-06-13T16:44:27-04:00] [webcache] [ERROR:32] [WXE-11904] [security] [ecid: ] SSL handshake fails SSL-29049
[2013-06-13T16:44:27-04:00] [webcache] [WARNING:1] [WXE-11905] [security] [ecid: ] SSL additional information: The record type is unknown.
[2013-06-13T16:44:27-04:00] [webcache] [WARNING:1] [WXE-11905] [security] [ecid: ] SSL additional information: Remote IP [163.118.22.16]:55144
[2013-06-13T16:44:27-04:00] [webcache] [WARNING:1] [WXE-11905] [security] [ecid: ] SSL additional information: Local IP 163.118.170.70:4448
[2013-06-13T16:44:27-04:00] [webcache] [WARNING:1] [WXE-11906] [security] [ecid: ] SSL details: SSL error during handshake (details: internal=The record type is unknown. system=Success)
[2013-06-13T16:44:27-04:00] [webcache] [ERROR:32] [WXE-11904] [security] [ecid: ] SSL handshake fails SSL-29049
[2013-06-13T16:44:27-04:00] [webcache] [WARNING:1] [WXE-11905] [security] [ecid: ] SSL additional information: The record type is unknown.
[2013-06-13T16:44:27-04:00] [webcache] [WARNING:1] [WXE-11905] [security] [ecid: ] SSL additional information: Remote IP [163.118.22.16]:55148
[2013-06-13T16:44:27-04:00] [webcache] [WARNING:1] [WXE-11905] [security] [ecid: ] SSL additional information: Local IP 163.118.170.70:4448
[2013-06-13T16:44:27-04:00] [webcache] [WARNING:1] [WXE-11906] [security] [ecid: ] SSL details: SSL error during handshake (details: internal=The record type is unknown. system=Success)
[2013-06-13T16:44:35-04:00] [webcache] [ERROR:32] [WXE-11904] [security] [ecid: ] SSL handshake fails SSL-28864
[2013-06-13T16:44:35-04:00] [webcache] [ERROR:32] [WXE-11904] [security] [ecid: ] SSL handshake fails SSL-28864
[2013-06-13T16:44:47-04:00] [webcache] [WARNING:1] [WXE-11905] [security] [ecid: ] SSL additional information: This error occurred because the peer closed the connection.
[2013-06-13T16:44:47-04:00] [webcache] [WARNING:1] [WXE-11906] [security] [ecid: ] SSL details: success during initialization (details: internal=success system=Success)
[2013-06-13T16:44:47-04:00] [webcache] [WARNING:1] [WXE-11905] [security] [ecid: ] SSL additional information: This error occurred because the peer closed the connection.
[2013-06-13T16:44:47-04:00] [webcache] [WARNING:1] [WXE-11906] [security] [ecid: ] SSL details: success during initialization (details: internal=success system=Success)
[2013-06-13T16:44:47-04:00] [webcache] [WARNING:1] [WXE-11905] [security] [ecid: ] SSL additional information: This error occurred because the peer closed the connection.
[2013-06-13T16:44:47-04:00] [webcache] [WARNING:1] [WXE-11906] [security] [ecid: ] SSL details: success during initialization (details: internal=success system=Success)
[2013-06-13T16:44:47-04:00] [webcache] [WARNING:1] [WXE-11905] [security] [ecid: ] SSL additional information: This error occurred because the peer closed the connection.
[2013-06-13T16:44:47-04:00] [webcache] [WARNING:1] [WXE-11906] [security] [ecid: ] SSL details: success during initialization (details: internal=success system=Success)
[2013-06-13T16:44:47-04:00] [webcache] [WARNING:1] [WXE-11905] [security] [ecid: ] SSL additional information: This error occurred because the peer closed the connection.
[2013-06-13T16:44:47-04:00] [webcache] [WARNING:1] [WXE-11906] [security] [ecid: ] SSL details: success during initialization (details: internal=success system=Success)
[2013-06-13T16:44:47-04:00] [webcache] [WARNING:1] [WXE-11905] [security] [ecid: ] SSL additional information: This error occurred because the peer closed the connection.
[2013-06-13T16:44:47-04:00] [webcache] [WARNING:1] [WXE-11906] [security] [ecid: ] SSL details: success during initialization (details: internal=success system=Success)
[2013-06-13T16:45:18-04:00] [webcache] [WARNING:1] [WXE-11905] [security] [ecid: ] SSL additional information: This error occurred because the peer closed the connection.
[2013-06-13T16:45:18-04:00] [webcache] [WARNING:1] [WXE-11906] [security] [ecid: ] SSL details: success during initialization (details: internal=success system=Success)
[2013-06-13T16:45:22-04:00] [webcache] [ERROR:32] [WXE-11904] [security] [ecid: ] SSL handshake fails SSL-28864
[2013-06-13T16:45:22-04:00] [webcache] [ERROR:32] [WXE-11904] [security] [ecid: ] SSL handshake fails SSL-28864
[2013-06-13T16:45:38-04:00] [webcache] [WARNING:1] [WXE-11905] [security] [ecid: ] SSL additional information: This error occurred because the peer closed the connection.
[2013-06-13T16:45:38-04:00] [webcache] [WARNING:1] [WXE-11906] [security] [ecid: ] SSL details: success during initialization (details: internal=success system=Success)
[2013-06-13T16:45:38-04:00] [webcache] [WARNING:1] [WXE-11905] [security] [ecid: ] SSL additional information: This error occurred because the peer closed the connection.
[2013-06-13T16:45:38-04:00] [webcache] [WARNING:1] [WXE-11906] [security] [ecid: ] SSL details: success during initialization (details: internal=success system=Success)
[2013-06-13T16:45:38-04:00] [webcache] [WARNING:1] [WXE-11905] [security] [ecid: ] SSL additional information: This error occurred because the peer closed the connection.
[2013-06-13T16:45:38-04:00] [webcache] [WARNING:1] [WXE-11906] [security] [ecid: ] SSL details: success during initialization (details: internal=success system=Success)
[2013-06-13T16:45:38-04:00] [webcache] [WARNING:1] [WXE-11905] [security] [ecid: ] SSL additional information: This error occurred because the peer closed the connection.
[2013-06-13T16:45:38-04:00] [webcache] [WARNING:1] [WXE-11906] [security] [ecid: ] SSL details: success during initialization (details: internal=success system=Success)
[2013-06-13T16:45:41-04:00] [webcache] [WARNING:1] [WXE-11905] [security] [ecid: ] SSL additional information: This error occurred because the peer closed the connection.
[2013-06-13T16:45:41-04:00] [webcache] [WARNING:1] [WXE-11906] [security] [ecid: ] SSL details: success during initialization (details: internal=success system=Success)
Any help or suggestions are greatly appreciated
Tnx a lot,
Lokesh

Hello ,
Try Below Workarounds:
Workaround 1:
Open Central Admin
àApplication Management à
Configure Alternate access mapping-->Edit your web application zone and add your server name in Intranet zone. So default can be serverIP and intranet could be servername.
Workaround 2:
Might be there is some issue with DNS and try to check that WebApplication is pointing to correct IP or not.
Also try to access your Sharepoint site using ip Address .. If you still gets error Kindly share the logs ..
Best
Regards Kuldeep Verma
Please remember to click "Mark As Answer"
if a post solves your problem or "Vote As Helpful" if it was useful.

FRM-92101: Load Balancing Forms 10g with Web Cache

Hi,
IÂ´m having some problems with Oracle Forms and Webcache 10g and I was wondering if you
could help.
Machines: (Pentium IV 2.6 GHz; 2GB RAM; 80GB HD)
A. Red Hat Linux AS 2.1
Oracle AS 10g - Infrastructure Installation
B. Windows 2000 Server - Service Pack 4
Oracle AS 10g - BI and Forms Installation (Using Infrastructure on machine A)
C. Windows 2000 Server - Service Pack 4
Oracle AS 10g - BI and Forms Installation (Using Infrastructure on machine A)
I didnÂ´t apply any Patchsets of Oracle AS 10g. My current version is 9.0.4.0 .
Goal:
Use Oracle Webcache 10g on machine B for Load Balancing an Oracle Forms Application
on machines B and C.
Facts:
The Oracle AS 10g installation on the 3 machines was made without problems.
The Forms Applications are running without problems on both Forms servers in machine B and C.
Symptoms:
IÂ´m getting the following error when I try to acces the forms application through Webcache:
FRM-92101: There was a failure in the forms server during startup.
This could happen due to invalid configuration.
Please look in the web-server log file for details.
But, this error happens ONLY when BOTH OC4J_BI_Forms instances (machines B and C) are
running.
When just one of the OC4J_BI_Forms is running everything works fine.
Webcache Configuration:
IÂ´ve followed Metalink note 207668.1: Configuring Web Cache as a Load Balancer for Application Servers
step by step to make the configuration of the following components:
1. Configuration of the origin servers
2. Configuration of Site definitions
3. Configuration of Site to server mapping
After that, IÂ´ve follwed the Metalink note 229900.1: Integrating and using Web Cache with Forms 9i for Load Balancing
step by step to make the configuration of the following components:
4. Session Binding
Then I try to test the Load Balancing and I got the error FRM-92101 when both OC4J_BI_Forms
instance were running.
IÂ´ve searched Metalink and found note 268830.1: Webcache Won't Load Balance 2 Forms Instances.
Following the note instructions I did the following changes:
Added these lines at the end of HTTPD.conf (machine B):
CookieTracking On
CookieName myformscookie1
Added these lines at the end of HTTPD.conf (machine C):
CookieTracking On
CookieName myformscookie2
In Webcache configuration:
IÂ´ve Changed the default session binding from JSESSIONID to "ANY SET COOKIE" for the
site's session binding.
But even after these changes IÂ´m getting FRM-92101 error on the same conditions.
How can I solve this problem ?
Thank you in advance.
Marcus Santos.
([email protected])

Just ran into this problem last Tuesday, Nov.30 and applied the changes today.
My configuration is similar to yours: 9.0.4 web cache on machine A, 9.0.4 10gAS forms and reports standalone on machine B and C (not a cluster, no infra).
I appended the Cookie lines you mentioned in httpd.conf located in $ORACLE_HOME/Apache/Apache/conf in both machines B and C.
One important thing you may have missed. After changing httpd.conf in each 9iAS instance, you need to make the change known to dcmctl so issue:
dcmctl updateConfig -ct ohs
Then do the following for each 9iAS instance and it should be ready for webcache:
dcmctl stop
dcmctl start
Setup Any-set-Cookie in webcache instead of JSESSIONID and the whole thing should now work. You can run a form through machine A which will load balance to either machine B or C (which can both be up). Then, try shutting down 9iAS on machine B or C and run a form again. They now all work.
HTH,
Raffy

Web cache load balancing web forms - Urgent

Hi,
I have two servers(server 1 and server 2) with BI(forms and reports) installation. Infrastructure is running on another unix server( server 3).
I can access forms application on server A and server B using URL :
http://server1.gnb.ca:7778/forms90/f90servlet?config=test
http://server2.gnb.ca:7778/forms90/f90servlet?config=test
Web cache is installed on both server 1 and server 2.
I want to load balance forms applications using web cache.I looked in metalink and i din't find a detailed document to do this.
specially i am not clear on What parameters / how to setup
1) site information for application
2) origin server
3) site to server mapping
I am following doc # 229900.1 from metalink. If someone can give steps to do this is appreciated.
Thanks

Hi, I can't exactly answer this as am not aware of Forms. But, as such, Web Cache does a good load balancing work provided you configure it well. Probably, you should try posting this in Forms forum too.
Regards,
Priyanka GES

Web Cache Error

We are occassionally getting the following error in various scenarios -- in development or just browsing the site:
"Oracle Web Cache Network Error"
Oracle Web Cache encountered a network error when communicating with the application web server.
We have Web Cache installed on the same server as the portal application, but an Oracle consultant who was in a few weeks ago said we had more than enough capacity. Any ideas? We're on Oracle Portal Version: 3.0.9.8.2 and

The error you are seeing is usually the result of a slow response from your origin server, although it could be something else. If you provide
a snippet of your Web Cache event log (verbose), I'll be able to assist you better.
For now, let's assume it is due to a slow origin server response. On a cache miss, if the Web Cache doesn't receive a response
from the origin server within a given time interval, it will close the connection with the origin server and respond to the browser with
a network apology page. This is the page you are seeing. There are ways to correct this.
First of all, you should modify the network apology page in order to customize it for your application or web site. The file is located in the $ORACLE_HOME/webcache/docs directory.
If you're using Web Cache 9.0.2.x, the default origin server timeout is 3600 seconds. You probably won't have to change this, but if you want to, then
please refer to the "Oracle9iAS Web Cache v9.0.2.0 Administration and Deployment Guide", available on OTN.
The relevant section is" Chapter 6, Task 7: Configure Network Timeouts."
If you're running Web Cache 2.0.0.x, the default origin server response timeout is 30 seconds. This default was chosen because we felt
that no application should take more than 30 seconds to respond to a user's request. Since then, we've learned that a lot of apps out there,
especially business intelligence apps, have complex queries that take several minutes, if not hours, to complete. To change this default timeout, you need to modify your internal.xml
file. Here's a snippet from the 2.0.0.4 readme.html file describing how to do this:
3.0 Network Apology Pages
When Oracle Web Cache sends requests to an application Web server, Oracle Web Cache permits the application Web server 30 seconds in which to
generate a response for the browser. If the application is unable to generate a response within that time, Oracle Web Cache sends a network apology
page to the browser.
If 30 seconds is not sufficient, then you can change the default settings of the OSSEND_TIMEOUT and OSRECV_TIMEOUT attributes in the
internal.xml file:
OSSEND_TIMEOUT: Network round-trip time (latency) between Oracle Web Cache and the application Web server. The 20 second default of
the OSSEND_TIMEOUT attribute is usually sufficient for most operating systems.
You can determine the latency to the application Web server by issuing the the following command from the Oracle Web Cache computer:
ping -s application_Web_server
This command provides output similar to the following:
PING sales.us.acme.com: 56 data bytes
64 bytes from sales.us.acme.com (130.35.45.34): icmp_seq=0. time=20. ms
64 bytes from sales.us.acme.com (130.35.45.34): icmp_seq=0. time=21. ms
If the time value is over 20 seconds, then increase the OSSEND_TIMEOUT attribute value.
OSRECV_TIMEOUT: Latency and application Web server processing time. The default is 30 seconds.
You can determine the processing time by sending a sample request to the application Web server and monitoring the time to process the
request. If the processing time is over 30 seconds, then increase the OSRECV_TIMEOUT attribute value.
To change these default settings:
1.Locate the following line in the internal.xml file:
<CALYPSONETINFO/>
2.Modify the <CALYPSONETINFO/> line as follows:
Add the OSSEND_TIMEOUT attribute as follows:
<CALYPSONETINFO OSSEND_TIMEOUT="seconds"/>
Add the OSSRECV_TIMEOUT attribute as follows:
<CALYPSONETINFO OSSRECV_TIMEOUT="seconds"/>
Add both the OSSEND_TIMEOUT and OSSRECV_TIMEOUT attributes as follows:
<CALYPSONETINFO OSSEND_TIMEOUT="time" OSRECV_TIMEOUT="time"/>

Oracle9iAS Web Cache for PL/SQL ????????

Hi,
I installed Oracle9iAS Web Cache.
I could cache any web site which write by asp, jsb,... but I can not cache web site http://www.vnn.vn because it write by pl/sql.
How do I cache web site which write by pl/sql, ex that web site.
Please, give me email follow address : [email protected]
Thanks
Nguyen Tien Dat

You should have no problem using Web Cache to accelerate a PL/SQL driven site. Any site that delivers content via HTTP is a good candidate for Web Cache. Try downloading the standalone Web Cache software from OTN, and be sure to read the manual to learn about how it works and how to configure it.

Web cache security

Hi,
I'm looking for some specific information on Web Caches security features. Interested in finding out how to configuring Web Cache to sit behind an Apache Server that handles single sign on and authentication.
Any help would be gratefully received.
Thanks.

Web Cache can sit in front of OHS/mod_osso. Mod_osso controls the caching policies of responses, basically making sure that protected content is never cached. There is a way to override this behavior for applications that need mod_osso for authentication but prefer to control caching policies themselves.
Web Cache has not been tested with 3rd-party authentication/authorization solutions.
Some applications use Web Cache like a repository. In order to generate a response, the app logic queries the cache to fetch objects (page metadata, login metadata, whatever) before assembling the final response and sending it back to the user.
Anyway, future releases of Web Cache will be able to deal with authorized/authenticated content in a much more sophisticated manner. But I can't go into details about that at this time.

Possible to use Web Cache to map sites to URL?

Similar Messages

Maybe you are looking for