Complex reports or long-running queries can cause SAS® Web Report Studio sessions to time out before the underlying operations complete. Each timeout can result in a pair of unresponsive, or deadlocked, threads. These threads accumulate over time, eventually rendering WebSphere non-functional.

Deadlocked threads never complete; the resources associated with the thread are never released. You might notice a degradation in performance as resources are consumed, and there will be hung-thread messages in the logs. If you monitor memory usage, you will notice a memory leak that is attributable to these deadlocked threads.

An application server has a finite number of available threads in its thread pool. When the pool is exhausted, the application server becomes unresponsive. An attempt to connect to any Web application will not complete.

It is also possible for the application server to run out of memory before the thread pool is exhausted. In this case, the application server will crash with an out-of-memory event, and you will not be able to connect at all.

Distinguishing This Problem from Other Unresponsive Conditions

If you are running SAS® Web Report Studio on a Web Application server that monitors its threads (such as WebSphere or WebLogic) you will see messages in the log indicating that threads are hung, stuck or otherwise long running.

In addition you will observe a clear increase in the memory that is used by the application server as the unresponsive threads accumulate. The parent thread has a pointer to the session (and, as such, to all of its session data). This session cannot be released until its parent thread is released. As a result, an indirect memory leak occurs that you can see in any memory monitor, as shown in the following example.

WebSphere messages

If you experience this problem running WebSphere, you will see the a WebSphere WSVR0605W error similar to the following in WebSphere's SystemOut.log file:

[2/22/10 11:06:13:792 EST] 0000000d ThreadMonitor W   WSVR0605W: Thread &qhot;WebContainer : 49040" 
(0000c1e0) has been active for 626596 milliseconds and may be hung.
There is/are 65 thread(s) in total in the server that may be hung.
[2/22/10 11:06:13:806 EST] 0000000d ThreadMonitor W   WSVR0605W: Thread "WebContainer : 49027" 
(0000c1d3) has been active for 740215 milliseconds and may be hung.  There is/are 66 thread(s) in total in the server that may be hung.

As shown in this example message, the unresponsive threads are "Webcontainer" threads, and you will notice that they come in pairs (these are the two deadlocked threads).

Weblogic messages

If this should occur in WebLogic, the corresponding WebLogic (BEA-000337) error will appear in the logs. Here is an example of the Weblogic stuck thread message:

<10-11-07 21:28:48>    <[STUCK] ExecuteThread: '1' for queue: 'weblogic.kernel.Default (self-tuning)' has been busy for " 618" seconds working on the request "Http Request: /SASWebReportStudio/exportReport.do", which is more than the configured time (StuckThreadMaxTime) of "600 " seconds. Stack trace:

Additionally, WebLogic is capable of detecting deadlocks directly. In that case, you might see the following message (BEA-000394) as well:

<10-11-07 21:29:48>    <
 
DEADLOCK DETECTED:
==================
 
[deadlocked thread] WRSThreadPool 3:
-----------------------------------
Thread 'WRSThreadPool 3' is waiting to acquire lock 'com.sas.apps.citation.model.user.Locks$RenderLock@2cac4d10' that is held by thread '[ACTIVE] ExecuteThread: '0' for queue: 'weblogic.kernel.Default (self-tuning)''

The Problem in Other Applications Servers

While this problem has only been observed in WebSphere and Weblogic, it is reasonable to suspect that this problem also might occur in other application servers (Red Hat JBoss, or Apache Tomcat).

Unfortunately applications servers that do not monitor unresponsive threads will give no warning or indication ahead of time. They will slowly degrade until the servers themselves become unresponsive or until they crash with an out-of-memory event.

Click the Hot Fix tab in this note to access the hot fix for this issue.

Operating System and Release Information

A fix for this issue for SAS Web Report Studio 4.2_M1 is available at:

A fix for this issue for SAS Web Report Viewer 4.2_M1 is available at:

A fix for this issue for SAS Web Report Studio 4.3 is available at:

A fix for this issue for SAS Web Report Viewer 4.3 is available at: