This article describes a workaround design that allows a Portal to survive if its resource starts hanging request threads.

Business Task
How frequently does your Portal experience user requests hanging in the resource? Not frequently, I hope. However, if this happens and the resource continues hanging user requests, the Portal is exposed to a fatal risk of spending all of the configured concurrent user requests and eventually dies. This is a disaster. I faced such situation a few times and decided to protect my Portal from even rare surprises such as these.

Let a Portal include several Portlets with login control provided via a backing file for each Portlet. The backing file is created per request and is thread-safe with regard to the user requests. In the login control, the baking file's init() method (or preRender() method) calls an API of separated security service (resource) to obtain a resource access authorization. For a business processing, Portlets also delegate user requests via other API calls to the business layer. Everything works fine until a call to the resource is not returned to the Portlet, i.e., it hangs somehow somewhere. Here is a concrete example.

We assume that WebLogic Portal uses EJB as a resource in the business layer and/or in security service. The EJB operates on other resources and reports processing status by sending a message via JMS. The EJB is deployed in a cluster together with other applications. Portal is deployed on a different physical machine. One of the co-deployed applications causes memory error and the whole cluster, including our EJB, hangs, i.e., it does not return requests and does not throw exceptions. Actually, it is not necessary to discuss such dramatic failure: "hanging" mode, from a Portal perspective, is just a response that returns too slowly, with too much latency to be acceptable in the dynamic concurrent life of the Portal. Latency may be caused, for instance, by server overload or problems with databases, but it is irrelevant - the threads in backing files run longer than allowed for normal Portal work and the "maximum number of concurrent users" in the Portal is reached. The Portal stops accepting user requests at all - this is the problem.

Solution Design
The first thing that came to my mind was to set a time-out on the RMI client, i.e., the EJB client, used by the Portlet to access its resource (remote-client-timeout). However, the WebLogic Guidelines on Using the RMI Timeout list several restrictions on such time-outs, including "No JMS resources are involved in the call." That is, I am not supposed to use a time-out for my resource EJB. I refer to this case for only one reason: to outline that there are situations where the Portal may be unprotected from hanged resource threads. Even if no restrictions would be applied to the time-out, if requests hang faster than the time-out frees related threads, the problem stays.

I would like to present one of the possible solutions for this problem. The solution is effective on one condition: the Portal has some contents or functions that are independent of potentially hanging resources. That is, Portal can operate with partial functionality.

The solution includes three components: Monitoring, Decision Rule, and the Rule Enforcement Method. The concept of the solution is straightforward: Portal monitors running calls to the resource, henceforth called resource threads, counts the amount of too long running resource threads (riskCounterValue) and applies a Decision Rule such as "If riskCounterValue reaches or exceeds predefined threshold - riskThreshold - all incoming calls to that resource are denied until riskCounterValue becomes smaller than riskThreshold." Due to the Rule, the number of potentially "hanged" resource threads gets limited and the user request may be served with reduced functionality. For example, if a Portal includes four Portlets, and some resource threads for one of the Portlets is considered "at risk of hanging," the Portal can skip the Portlet-in-risk and display just three Portlets to the user.

The implementation of the Rule Enforcement Method is very important. If the rule is enforced in the scope of every call, we may expect performance degradation but gain simplicity in the control of potentially "hanged" resource threads. If the rule is enforced outside of the calls, we can preserve performance but tuning of such control becomes tricky. We will discuss the latter case with details. The diagram in Figure 1 describes it.

As the diagram shows, in the first step the Portal initializes a Helper object that, in turn, initializes a CallRegistry object. The latter may be implemented as a java.util.HashMap and used for registering all calls to the resource API. Then Helper starts a "watchdog" thread. If you use Struts, for example, this thread starts in the Model. The "watchdog" thread periodically reviews records in the CallRegistry, counts the number of too long running calls, and sets it as a riskCounterValue variable in the Helper.

It is assumed that we approximately know normal execution time of API calls. This may be one value for all APIs - the longest duration - or every API may have its individual execution time. Therefore, when an API method is invoked, we can calculate the time at which the API is expected to complete in a normal situation, for example:

java.lang.System.currentTimeMillis()
long apiExecutionTime = ...;// property
long timeToComplete =
      java.lang.System.currentTimeMillis() + apiExecutionTim

When a Helper's method is called, it adds a new record into the CallRegistry. The record consists of a unique Call ID (used as a key in the java.util.HashMap) and expected completion time (timeToComplete) for the API (used as a value in the java.util.HashMap). If the method successfully completes, it removes its record from the CallRegistry.

Let's review how a user request is processed. Upon receiving a user request, the Portlet's backing file delegates it to the Helper API method (the latter invokes the resource API). First the Helper API method checks if it may execute. If the riskThreshold is not reached by the moment of the request, the Helper API method continues its work. Otherwise, it throws an exception and the Portal moves to the next function or next API call.

The permission to execute may be given only if the amount of too long running resource threads (riskCounterValue) is less than the riskThreshold. The riskThreshold is set via configuration properties. For example, if the maximum of concurrent user requests is configured as 25, the riskThreshold may be set to 10. That is, the Portal risks only a half of its capability of handling concurrent user requests and it still can operate if resource threads start to hang.

Notice that we do not do anything with too long running API calls. Some of them can eventually complete successfully and Helper API methods will remove their records from the CallRegistry, i.e., the next route of counting may result in lower number than the riskThreshold and the next user request for the resource may not be denied (by throwing an exception).

The Portal cannot know if there is an accidental latency in the network or if the resource thread is really hanging. Because of that, it is recommended to send a notification (e.g., via an e-mail) to the Operation Team if the riskThreshold is reached or exceeded in several sequential control cycles. Received notification will allow the Operation Team to analyze logs promptly, and find and resolve the reason of long running calls in timely manner.

Analysis and Tuning
A control of "hanged" resource threads is quite dynamic and not simple in tuning. Its effectiveness is based on the balance of three parameters:

• ratio of average period of time (TUR) between user requests to period of time (TRC) between "watchdog" thread control cycles - risk control cycles: R = TUR / TRC
• risk threshold (riskThreshold) for a particular resource
• expected time of execution of the resource API calls