Portlet Timeout Sample
This sample shows a technique for releasing portlet data for portlets that haven't been accessed recently. This technique can supplement other steps that should be taken in order to keep the amount of session data small. For example, you can use the Discardable Variable functionality, and you can use stateless provider models. You can use the session size tracing feature to confirm the impact on session variable usage of this code and the other techniques.
All the needed support in this sample is in the PortletTimeoutSupport model. To use it in a portlet model, just do an Imported Model of PortletTimeoutSupport. There are three sample portlets: Portlet1, Portlet2, Portlet3 that import the support model, for testing. There's also a StandaloneContainer model that you can run standalone (not in Portal) to see the behavior.
The portlet timeout period can be specified in override.properties (it's read using a BSConfig method). The timeout length is specified in milliseconds. The default is 10 minutes.
The main logic is in the TimeoutHelper class. It has an event handler for OnRequest, which sets the lastAccessTime for the model, then fires the PORTLET_ACCESSED event.
Portlets then have an event handler for PORTLET_ACCESSED, so other portlets with this code will receive the event, check their lastAccessTime, and free their state data if it's timed out. This PORTLET_ACCESSED handler is defined in the PortletTimeoutSupport model.
Data is cleared out in the method resetInstanceVariables. Each variable is set to its default value if there is one, or to null otherwise.
When the data is reset (resetInstanceVariables), the current page is set to reinitializeAction. This causes the next execution of the portlet to call that method (as if it was the current page). reinitializeAction fires an OnWebAppLoad event and calls the "main" method, so that portlet initialization is performed for the portlet after it times out.
The code logs information in Server Stats, so you can see how many models were timed out during each 5-minute snapshot interval in the serverStats file (e.g. ModelTimeouts: 2).
There are some printlns in the Java code so you can verify behavior; those should be removed before putting into production.
This support depends on the OnRequest event, which is fired on all top-level portlet models. If you want the timeout support for contained models, you will need to select the option for "Forward Request Events" in the Model Container builder (in the portlet model). The OnRequest event is not fired for service provider models, so you can't use this in a provider model alone. For service provider models, the best practice is to make them stateless, in which case they won't maintain any session data anyway.
PortletTimeoutSupport.model – this contains all the builders needed for the timeout support, and can be incorporated in models using Imported Model
PortletTimeoutSample.model – this is a test model which displays the model name and the value of a “requestCounter” variable. This model also imports the PortletTimeoutSupport model to provide the timeout functionality. This model is in turn imported into the three main test portlets below.
Portlet1.model, Portlet2.model, Portlet3.model – These are the three main test portlets. They all use Imported Model to include the PortletTimeoutSample model.
StandaloneContainer.model – This is a test container for testing the timeout support in standalone mode. This model displays the Portlet1 and Portlet2 models using Model Container; note that the option for “Forward Request Events” is enabled in the Model Container builders.
TimeoutHelper.java – The Java LJO code that does the work of releasing variables when a portlet has timed out. This also fires the PORTLET_ACCESSED event when an OnRequest is received.