As we all know, facing issues in a software project is quite common. But it becomes difficult when you get stuck somewhere and start searching different sites for a solution without knowing what the actual root cause is.
For many production issues, application logs are the first place to start. If the logs are not enough, we may need to go deeper by looking at thread dumps and other server-level information.
One issue I faced in WebLogic was "stuck (hogging) threads". There is no single solution for this issue because the actual cause can be different depending on the application and the request being processed.
For many production issues, application logs are the first place to start. If the logs are not enough, we may need to go deeper by looking at thread dumps and other server-level information.
One issue I faced in WebLogic was "stuck (hogging) threads". There is no single solution for this issue because the actual cause can be different depending on the application and the request being processed.
What is a Hogging / Stuck Thread?
A WebLogic execute thread is considered stuck when it has been working continuously for longer than the configured `StuckThreadMaxTime`.
The default value of
A stuck thread does not necessarily mean that the thread will never return or release its resources. It means that the request has been running for longer than the configured threshold and WebLogic has identified it as a potentially problematic thread.
A WebLogic execute thread is considered stuck when it has been working continuously for longer than the configured `StuckThreadMaxTime`.
The default value of
StuckThreadMaxTime is 600 seconds, although this can be changed through the WebLogic configuration.A stuck thread does not necessarily mean that the thread will never return or release its resources. It means that the request has been running for longer than the configured threshold and WebLogic has identified it as a potentially problematic thread.
The Issue I Faced
I faced a stuck-thread issue in one of my projects when the support team reported that several WebLogic threads were showing as stuck. The first step was to look at the WebLogic error log and then investigate the thread stack trace to understand what the thread was actually waiting for.
A simplified version of the error looked like this:
I faced a stuck-thread issue in one of my projects when the support team reported that several WebLogic threads were showing as stuck. The first step was to look at the WebLogic error log and then investigate the thread stack trace to understand what the thread was actually waiting for.
A simplified version of the error looked like this:
[STUCK] ExecuteThread: '452' for queue:
'weblogic.kernel.Default (self-tuning)' has been busy for
"697" seconds working on the request.
This is more than the configured StuckThreadMaxTime
of "600" seconds.
The important part of the stack trace in my case was:
From the stack trace, the thread was waiting while trying to obtain a database connection.
This was an important clue because the problem was not simply a WebLogic configuration issue. We needed to understand "why the request was taking so long and why the thread was waiting for a database connection"
Blocked trying to get lock:
weblogic.jdbc.common.internal.GenericConnectionPool
ResourcePoolImpl.reserveResourceInternal(...)
ConnectionPool.reserve(...)
ConnectionPoolManager.reserve(...)
RmiDataSource.getConnection(...)
...
HibernateTransactionManager.doBegin(...)
...
JwsCentreService.getXXXXameList(...)
From the stack trace, the thread was waiting while trying to obtain a database connection.
This was an important clue because the problem was not simply a WebLogic configuration issue. We needed to understand "why the request was taking so long and why the thread was waiting for a database connection"
There can be several reasons for stuck threads. Some common possibilities are:
- Network issues
- Application issues
- Dependent service issues
- Database/connection-pool issues
- Heavy server load
- Long-running operations
- Incorrect timeout configuration
Therefore, simply increasing `StuckThreadMaxTime` may hide the symptom without fixing the actual problem.
Possible Solutions
If the application itself looks healthy, I would check the dependent services, connection pools, timeout settings, and WebLogic configuration. In my case, the application was running on "Oracle Service Bus (OSB)" and the issue was related to communication between proxy services and business services.
If the application itself looks healthy, I would check the dependent services, connection pools, timeout settings, and WebLogic configuration. In my case, the application was running on "Oracle Service Bus (OSB)" and the issue was related to communication between proxy services and business services.
1. Check Connection and Read Timeout
The first thing I checked was the connection timeout and read timeout configured for the business service. If a downstream service takes too long to respond, the WebLogic execute thread can remain occupied while waiting for that response. Check whether the configured timeout values are appropriate for the application and the dependent service.
For example, if the expected response time is around 30 seconds, the timeout should be configured accordingly rather than allowing requests to remain active for several minutes. The exact timeout value should depend on the application's requirements. There is no universal value that is correct for every system.
The first thing I checked was the connection timeout and read timeout configured for the business service. If a downstream service takes too long to respond, the WebLogic execute thread can remain occupied while waiting for that response. Check whether the configured timeout values are appropriate for the application and the dependent service.
For example, if the expected response time is around 30 seconds, the timeout should be configured accordingly rather than allowing requests to remain active for several minutes. The exact timeout value should depend on the application's requirements. There is no universal value that is correct for every system.
2. Use a Separate Work Manager
The second thing I tried was creating a separate Work Manager for the proxy service instead of using the default Work Manager.
In my case, the proxy service was using the default Work Manager. After configuring a separate Work Manager for the affected service, the issue was resolved. This approach can help isolate workloads and prevent one type of request from consuming resources needed by other applications or services.
The second thing I tried was creating a separate Work Manager for the proxy service instead of using the default Work Manager.
In my case, the proxy service was using the default Work Manager. After configuring a separate Work Manager for the affected service, the issue was resolved. This approach can help isolate workloads and prevent one type of request from consuming resources needed by other applications or services.
What I Learned
A stuck-thread message by itself does not tell you the root cause.The important part is to look at the (thread dump / stack trace) and identify what the thread is actually doing or waiting for.
For example, if the thread is waiting for:
A stuck-thread message by itself does not tell you the root cause.The important part is to look at the (thread dump / stack trace) and identify what the thread is actually doing or waiting for.
For example, if the thread is waiting for:
- A database connection → investigate the connection pool and database
- A remote service → investigate network and service response time
- A lock → investigate thread contention
- Application code → investigate the corresponding application logic
In my case, the stack trace showed that the thread was waiting while trying to obtain a database connection, which helped narrow down the investigation.
So, whenever you see a WebLogic stuck-thread warning, don't immediately increase `StuckThreadMaxTime`. First try to understand "why the thread has been running for so long".
So, whenever you see a WebLogic stuck-thread warning, don't immediately increase `StuckThreadMaxTime`. First try to understand "why the thread has been running for so long".
Hopefully, this experience helps someone who is troubleshooting a similar Web Logic issue.
