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

Related Topics: Weblogic

Weblogic: Article

Common WebLogic Server Deadlocks and How To Avoid Them

Common WebLogic Server Deadlocks and How To Avoid Them

Every developer has experienced it. The application that ran so well in testing hangs or performs miserably under load.

While there are many possible causes of performance degradation or hangs, this article can't possibly cover them all. Instead, we'll look at three common mistakes in WebLogic Server applications that can deadlock the server or bring your performance to a screeching halt.

Thread Dumps
The best Java tool for diagnosing deadlocks is a Java virtual machine thread dump. A thread dump is a snapshot of the virtual machine's current state, including stack traces for each Java thread. Many virtual machines also include information about the Java monitors held by each thread. Monitor information is especially useful for diagnosing deadlocks and performance problems in your application. On Windows platforms, you can generate a thread dump by pressing Ctrl-Break in the virtual machine's window. On Unix systems, a SIGQUIT signal must be sent to the Java virtual machine process. This can be done with a kill -3 <process id>.

Deadly Embrace
The classic deadlock problem is the deadly embrace: Thread 1 owns Lock A and waits on Lock B, Thread 2 owns Lock B and waits on Lock A. These threads are deadlocked and will remain blocked in this state. In many cases, the remaining threads will eventually enter the deadlock by attempting to acquire Lock A or Lock B and waiting. For instance, you might have a servlet that calls a synchronized method on the B object. If B's monitor is already held in a deadlock, any subsequent servlet request that attempts to acquire that monitor will enter the deadlock.

A thread dump is one of the best ways to discover a deadly embrace deadlock. Most virtual machines include a thread state for each Java thread in the dump. The most common thread states are: R - running; MW - monitor wait; CW - condition wait. Threads in the MW state are blocked, waiting to enter a synchronized block and acquire a Java monitor. Since the thread dump includes the Java thread's stack trace, it's also possible to determine which monitor is blocking the thread. If multiple threads are in the MW state on the same monitor, it's a good indication that there's either a lot of contention for this monitor, or the server is deadlocked. In a deadlock situation, you should be able to determine the other threads blocked in MW and their held monitors.

There are two classic techniques for solving deadly embrace deadlocks: deadlock avoidance and deadlock detection. Deadlock avoidance is merely changing or structuring your code so that it can't hit the deadlock case. A common solution is to implement lock ordering. If Lock A is always acquired before Lock B then you can't have a deadly embrace on these two locks. It's also a good idea to minimize the time that a monitor is held. Every extra line of code that runs under a monitor is another chance for someone to add a deadlock. Deadlock detection is commonly implemented by databases for their locks, but it doesn't usually find its way into programming languages. In deadlock detection, deadlocks are automatically discovered and one or more deadlock participants (known as the victims) are killed and release their locks to break the deadlock. Java virtual machines do not break deadlocks on Java monitors, so deadlock avoidance is necessary.

Out-of-Threads Deadlock
Another common way to deadlock an application is what I call the "out of threads" deadlock. Unfortunately, this deadlock often doesn't show up until a load test or, in the worst case, when your production application receives a lot of traffic. In this scenario, your WebLogic Server is running with a fixed number of threads. The application includes logic where a given request or action performs work in one thread and then blocks on work that must be done in another thread.

For instance, an application might open an HTTP socket connection to its own server instance, post a request, and wait for a response. If all threads post at the same time, there are no available threads to generate a response. Another common scenario is when Server A makes an RMI call to Server B and blocks waiting for a response. Server B then calls back into A before it generates the response to A's initial call. If all threads in A are exhausted then A is waiting for B's response, and B is waiting for A's response.

The first clue in an "out of threads" dump is that there are no idle WebLogic Server Execute Threads. The Execute Threads are the worker threads in the server that run the application code. An idle ExecuteThread will be in condition wait (CW) in a method named ExecuteThread.waitForRequest. This thread is available and waiting for incoming work. In an "out of threads" deadlock, you won't see any idle threads, and all other worker threads will be blocked, usually waiting for a response.

Unfortunately, determining that there are no idle threads is slightly more complicated than just searching for ExecuteThread.waitForRequest. WebLogic Server uses thread pools internally to avoid having to continually create new threads. It also offers multiple thread pools and uses several different thread pools within the server. Thread pools would be a good topic for an entire article so we won't cover them in detail here, but it's important to understand for this topic that most user work is performed on the "default" queue. In an "out of threads" deadlock, it's important to note whether there are no idle threads on the "default" queue.

The best way to avoid "out of threads" deadlocks is to analyze your architecture and remove the common mistakes that produce these deadlocks. In particular, never open a socket connection to your own server instance. Also, avoid synchronous request/response APIs that include callbacks. In general, asynchronous communication works well for server-to-server or application-to-application calls. Both messaging (JMS) and Web services include asynchronous support. One of the advantages of asynchronous communication is that the calling thread is not blocked waiting for the response.

Monitors and External Systems
In addition to diagnosing deadlocks, thread dumps can be useful for analyzing performance problems. One architectural mistake that is often evident from thread dumps is holding Java monitors while making external requests. For instance, an application might enter a synchronized block on its business data object and then log some information on an external system. In the common case, this might work fine if the logging to the external system is running relatively quickly. However, it really runs into trouble under load. In a production system, the external system is probably slower, and there are many concurrent requests trying to get access to the monitor. Usually, the entire system slows down dramatically and essentially becomes single-threaded.

The "single-threaded" problem shows up in thread dumps when there are many threads that are blocked in MW for the same monitor. There is then a single thread that already owns the monitor and is often blocked waiting for some external system to return. For instance, it's often blocked waiting for a network socket read to return. In thread dumps that display the current monitor owners, it's obvious which thread holds the contested monitor. In less verbose thread dumps, you'll have to analyze the stack trace for each thread and determine which monitors it's holding. Since a monitor is only ever owned by one thread, this is not as bad as it initially sounds.

The "single-threaded" problem can be avoided by never holding Java monitors while making requests to external systems. Fundamentally, holding monitors and running someone else's code is inviting deadlock or extremely poor performance. The external system may be down, performing slowly, or blocked on some other resource. If your application is holding a Java monitor, these external events can drastically reduce your performance to a crawl.

This article demonstrates some common WebLogic Server application mistakes and how they contribute to deadlocks or poor performance. Thread dumps are invaluable in debugging these types of problems. Hopefully, the techniques in this article will help you find your way out the next time your application becomes unresponsive.

Comments (0)

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.

IoT & Smart Cities Stories
Discussions of cloud computing have evolved in recent years from a focus on specific types of cloud, to a world of hybrid cloud, and to a world dominated by the APIs that make today's multi-cloud environments and hybrid clouds possible. In this Power Panel at 17th Cloud Expo, moderated by Conference Chair Roger Strukhoff, panelists addressed the importance of customers being able to use the specific technologies they need, through environments and ecosystems that expose their APIs to make true ...
"Space Monkey by Vivent Smart Home is a product that is a distributed cloud-based edge storage network. Vivent Smart Home, our parent company, is a smart home provider that places a lot of hard drives across homes in North America," explained JT Olds, Director of Engineering, and Brandon Crowfeather, Product Manager, at Vivint Smart Home, in this SYS-CON.tv interview at @ThingsExpo, held Oct 31 – Nov 2, 2017, at the Santa Clara Convention Center in Santa Clara, CA.
We are seeing a major migration of enterprises applications to the cloud. As cloud and business use of real time applications accelerate, legacy networks are no longer able to architecturally support cloud adoption and deliver the performance and security required by highly distributed enterprises. These outdated solutions have become more costly and complicated to implement, install, manage, and maintain.SD-WAN offers unlimited capabilities for accessing the benefits of the cloud and Internet. ...
In an era of historic innovation fueled by unprecedented access to data and technology, the low cost and risk of entering new markets has leveled the playing field for business. Today, any ambitious innovator can easily introduce a new application or product that can reinvent business models and transform the client experience. In their Day 2 Keynote at 19th Cloud Expo, Mercer Rowe, IBM Vice President of Strategic Alliances, and Raejeanne Skillern, Intel Vice President of Data Center Group and G...
Business professionals no longer wonder if they'll migrate to the cloud; it's now a matter of when. The cloud environment has proved to be a major force in transitioning to an agile business model that enables quick decisions and fast implementation that solidify customer relationships. And when the cloud is combined with the power of cognitive computing, it drives innovation and transformation that achieves astounding competitive advantage.
DXWorldEXPO LLC announced today that "IoT Now" was named media sponsor of CloudEXPO | DXWorldEXPO 2018 New York, which will take place on November 11-13, 2018 in New York City, NY. IoT Now explores the evolving opportunities and challenges facing CSPs, and it passes on some lessons learned from those who have taken the first steps in next-gen IoT services.
The current age of digital transformation means that IT organizations must adapt their toolset to cover all digital experiences, beyond just the end users’. Today’s businesses can no longer focus solely on the digital interactions they manage with employees or customers; they must now contend with non-traditional factors. Whether it's the power of brand to make or break a company, the need to monitor across all locations 24/7, or the ability to proactively resolve issues, companies must adapt to...
"IBM is really all in on blockchain. We take a look at sort of the history of blockchain ledger technologies. It started out with bitcoin, Ethereum, and IBM evaluated these particular blockchain technologies and found they were anonymous and permissionless and that many companies were looking for permissioned blockchain," stated René Bostic, Technical VP of the IBM Cloud Unit in North America, in this SYS-CON.tv interview at 21st Cloud Expo, held Oct 31 – Nov 2, 2017, at the Santa Clara Conventi...
Founded in 2000, Chetu Inc. is a global provider of customized software development solutions and IT staff augmentation services for software technology providers. By providing clients with unparalleled niche technology expertise and industry experience, Chetu has become the premiere long-term, back-end software development partner for start-ups, SMBs, and Fortune 500 companies. Chetu is headquartered in Plantation, Florida, with thirteen offices throughout the U.S. and abroad.
René Bostic is the Technical VP of the IBM Cloud Unit in North America. Enjoying her career with IBM during the modern millennial technological era, she is an expert in cloud computing, DevOps and emerging cloud technologies such as Blockchain. Her strengths and core competencies include a proven record of accomplishments in consensus building at all levels to assess, plan, and implement enterprise and cloud computing solutions. René is a member of the Society of Women Engineers (SWE) and a m...