Weblogic Authors: Yeshim Deniz, Elizabeth White, Michael Meiner, Michael Bushong, Avi Rosenthal

Related Topics: Weblogic

Weblogic: Article

WebLogic Journal: If a Resource Thread Hangs in the Portal

Workaround solution

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:

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
The research and testing of the control have concluded that parameter tunings depend on a particular Portal implementation but have common tendencies. The graph in Figure 2 demonstrates guidelines for the tuning. In the tests, the ratio was set as R = 95% where TUR was 95 [ms] while TRC was set as 100 [ms]. In general, a reliable ratio is 90% and higher.

More Stories By Michael Poulin

Michael Poulin works as an enterprise-level solution architect in the financial industry in the UK. He is a Sun Certified Architect for Java Technology, certified TOGAF Practitioner, and Licensed ZapThink SOA Architect. Michael specializes in distributed computing, SOA, and application security.

Comments (1) View Comments

Share your thoughts on this story.

Add your comment
You must be signed in to add a comment. Sign-in | Register

In accordance with our Comment Policy, we encourage comments that are on topic, relevant and to-the-point. We will remove comments that include profanity, personal attacks, racial slurs, threats of violence, or other inappropriate material that violates our Terms and Conditions, and will block users who make repeated violations. We ask all readers to expect diversity of opinion and to treat one another with dignity and respect.

Most Recent Comments
SYS-CON Belgium News Desk 02/22/06 02:31:27 PM EST

This article describes a workaround design that allows a Portal to survive if its resource starts hanging request threads. 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.

IoT & Smart Cities Stories
The challenges of aggregating data from consumer-oriented devices, such as wearable technologies and smart thermostats, are fairly well-understood. However, there are a new set of challenges for IoT devices that generate megabytes or gigabytes of data per second. Certainly, the infrastructure will have to change, as those volumes of data will likely overwhelm the available bandwidth for aggregating the data into a central repository. Ochandarena discusses a whole new way to think about your next...
Dynatrace is an application performance management software company with products for the information technology departments and digital business owners of medium and large businesses. Building the Future of Monitoring with Artificial Intelligence. Today we can collect lots and lots of performance data. We build beautiful dashboards and even have fancy query languages to access and transform the data. Still performance data is a secret language only a couple of people understand. The more busine...
DXWorldEXPO LLC announced today that Big Data Federation to Exhibit at the 22nd International CloudEXPO, colocated with DevOpsSUMMIT and DXWorldEXPO, November 12-13, 2018 in New York City. Big Data Federation, Inc. develops and applies artificial intelligence to predict financial and economic events that matter. The company uncovers patterns and precise drivers of performance and outcomes with the aid of machine-learning algorithms, big data, and fundamental analysis. Their products are deployed...
All in Mobile is a place where we continually maximize their impact by fostering understanding, empathy, insights, creativity and joy. They believe that a truly useful and desirable mobile app doesn't need the brightest idea or the most advanced technology. A great product begins with understanding people. It's easy to think that customers will love your app, but can you justify it? They make sure your final app is something that users truly want and need. The only way to do this is by ...
CloudEXPO | DevOpsSUMMIT | DXWorldEXPO are the world's most influential, independent events where Cloud Computing was coined and where technology buyers and vendors meet to experience and discuss the big picture of Digital Transformation and all of the strategies, tactics, and tools they need to realize their goals. Sponsors of DXWorldEXPO | CloudEXPO benefit from unmatched branding, profile building and lead generation opportunities.
Digital Transformation and Disruption, Amazon Style - What You Can Learn. Chris Kocher is a co-founder of Grey Heron, a management and strategic marketing consulting firm. He has 25+ years in both strategic and hands-on operating experience helping executives and investors build revenues and shareholder value. He has consulted with over 130 companies on innovating with new business models, product strategies and monetization. Chris has held management positions at HP and Symantec in addition to ...
Cell networks have the advantage of long-range communications, reaching an estimated 90% of the world. But cell networks such as 2G, 3G and LTE consume lots of power and were designed for connecting people. They are not optimized for low- or battery-powered devices or for IoT applications with infrequently transmitted data. Cell IoT modules that support narrow-band IoT and 4G cell networks will enable cell connectivity, device management, and app enablement for low-power wide-area network IoT. B...
The hierarchical architecture that distributes "compute" within the network specially at the edge can enable new services by harnessing emerging technologies. But Edge-Compute comes at increased cost that needs to be managed and potentially augmented by creative architecture solutions as there will always a catching-up with the capacity demands. Processing power in smartphones has enhanced YoY and there is increasingly spare compute capacity that can be potentially pooled. Uber has successfully ...
SYS-CON Events announced today that CrowdReviews.com has been named “Media Sponsor” of SYS-CON's 22nd International Cloud Expo, which will take place on June 5–7, 2018, at the Javits Center in New York City, NY. CrowdReviews.com is a transparent online platform for determining which products and services are the best based on the opinion of the crowd. The crowd consists of Internet users that have experienced products and services first-hand and have an interest in letting other potential buye...
When talking IoT we often focus on the devices, the sensors, the hardware itself. The new smart appliances, the new smart or self-driving cars (which are amalgamations of many ‘things'). When we are looking at the world of IoT, we should take a step back, look at the big picture. What value are these devices providing. IoT is not about the devices, its about the data consumed and generated. The devices are tools, mechanisms, conduits. This paper discusses the considerations when dealing with the...