Recently, threads of WebLogic applications have been STUCK for several times in a production system. As a result, threads of WebLogic are blocked, CPU usage increases, and WebLogic services are suspended.
Therefore, the state of Weblogic thread is summarized and classified.
ACTIVE threads:
Threads that are eligible to process incoming requests are classified as ACTIVE threads.
When thread demand increases, Weblogic will begin to raise threads from standby to active, which will enable them to handle future client requests
Block threads:
Weblogic.kernel. Default is the queue name of the thread generated after the client submits the request. The default number of threads in this queue is 30. If 30 threads are used up, especially a large number of sticky threads that cannot be released, the threads will be blocked and a large number of subsequent threads will be put into the block state. The deployed application cannot be accessed.
If a large number of such requests are sent, the WebLogic thread may be blocked or webLogic may be suspended.
You can solve the problem in the following ways:
1) Change the StuckThreadMaxTime parameter from the default 600s to 1200s, or whatever is appropriate.
2) Increase the number of threads MaxPoolSize to prevent thread blocking.
3) Optimize procedures and reduce processing time.
Stuck threads:
These are threads that take longer than the “maximum stuck thread time” (the default is 600 seconds). The default value of StuckThreadMaxTime is 10 minutes.
True if the executing thread is stuck processing a request for longer than the configured maximum time for a stuck thread.
This value can be increased or decreased by console Settings: Console >> Environment >> Server > MedRecSvr1 >> Configuration >> Optimization >> Maximum Stuck Thread Time.
However, changing this value does not make much sense. Most threads are Stuck because of an application exception, and adding time does not solve the problem.
WebLogic marks certain threads as Stuck threads to alert them that they are taking too long to execute.
You should analyze why threads take so long to complete (or even never complete).
A Hogging Thread:
True if, according to the scheduler’s automatic observation, a request monopolizes the thread of execution for longer than normal execution time.
WebLogic needs two conditions to mark a Thread as Hogging:
(1) The thread execution time exceeds normal Execution time.
(2) The thread execution time has not exceeded the “maximum stuck thread time”.
Over time, a Hogging Thread can change in two different states:
(1) Before the “maximum holdup time” is exceeded, the request is finished, the Hogging Thread is released, and the Hogging Thread returns to the Thread pool to wait for the next request.
A Hogging Thread is marked as Stuck until it finishes executing (although it may never finish) if the request does not finish executing after exceeding the “maximum Stuck time”.
STANDBY Thread:
Threads waiting to be marked as eligible to process incoming requests are classified as STANDBY threads. These threads remain in the standby pool. Threads that are not required to process the current workload are designated as standby threads and added to the standby pool.
These threads are activated when more threads are needed. These threads are created and visible from JVM thread dumps, but are not yet available to handle client requests.