Skip navigation.

Using WSRP with WebLogic Portal

  Previous Next vertical dots separating previous/next from contents/index/pdf Contents View as PDF   Get Adobe Reader

Local Proxy Support

Local proxy support allows co-located Producer and Consumer web applications to short-circuit network I/O and "SOAP over HTTP" overhead.

Note: If you run both the Consumer and Producer on the same server, a deadlock situation can potentially occur. This is because the Producer allocates a new thread for each portlet. When running the in local proxy mode, extra threads are not allocated. For this reason, using local proxy mode, as described in this section, is recommended whenever you are running both the Producer and Consumer in the same server.

When you enable this feature, the Consumer tries to determine if the Producer is deployed on the same server and, if it discovers that the Producer is so deployed, it uses a local proxy to send requests to the Producer. If the Producer is not deployed on the same server, the Consumer uses the default remote proxy. Remote Producers can still be invoked as usual even when the local proxy support is enabled.

This section describes how to implement local proxy support. It includes information on the following subjects:


Why Use Local Proxy Mode?

Local proxy mode provides a number of advantages over the default remote proxy when you are working with co-located web applications. Among the most significant are that it:

Additionally, by enabling local proxies, customers can take advantage of the decoupling benefits of WSRP without incurring its performance overhead.


Deployment Configuration

To take advantage of local proxy support, do the following:

  1. Deploy the Producer and Consumer web applications on the same server. These applications could be in the same enterprise application or across different enterprise applications.
  2. Enable local proxy support by setting <enable-local-proxy> to "true" in WEB-INF/wsrp-producer-registry.xml in the Consumer web application, as shown in Listing 7-1:


Listing 7-1 Setting <enable-local-proxy> to "true"

registry/8.0 wsrp-producer-registry.xsd">
   <!-- Upload limit (in bytes) -->
   <!-- Timeout (in milli seconds) -->
   <!-- Enable local proxy -->

You can also enable local proxy support by setting a system property com.bea.wsrp.proxy.LocalProxy.enabled = true. If this system property is set to true, it will override the <enable-local-proxy> setting in WEB-INF/wsrp-producer-registry.xml.

Local proxy support is disabled by default in web application templates.


When to Use and Not Use

As powerful a tool as local proxy support is, you should only use it when it will benefit your application. The most common reasons for using local proxy support are:

On the other hand, you shouldn't use local proxy support when interoperating with non-BEA Producers and Consumers.


Maintaining Session State

When a producer and consumer are deployed on the same server, it is possible that session state can be lost when a user interacts with portlets that are deployed in different web applications. This issue arises because, in terms of HTTP, the user is interacting with two separate web applications that set cookies with the same session ID (JSESSIONID) and path. For example, as shown in Figure 7-1, Cookie 1 and Cookie 2 have the same session name and path, and the browser simply replaces Cookie 1 with Cookie 2. As a result, the session state maintained by Cookie 1 for Web App 1 is lost.

Figure 7-1 Cookies are Overwritten

Cookies are Overwritten


To avoid this situation, manually change the cookie name in one of the web applications. To do this, edit the <session-descriptor> element of the application's weblogic.xml file as follows:


where JMYCOOKIE is a name you choose.


Skip navigation bar  Back to Top Previous Next