Why threads stuck in weblogic

June 7, at 2 h 34 min. Reply to Anil. Chandra Shekhar Manjhi says:. December 17, at 8 h 29 min. Reply to Chandra. Md Saddam Khan says:. July 24, at 11 h 58 min. Reply to Md. Stephane Biehler says:. July 24, at 13 h 19 min. GBRK says:. July 31, at 15 h 31 min. Reply to GBRK. Sunil says:. December 31, at 1 h 19 min. Reply to Sunil. Leave a Reply Cancel Reply My comment is..

Middleware Team. This website uses cookies to improve your experience. I am a pragmatic guy. I enjoy having little applications or tools to demonstrate and measure how WebLogic is working. After downloading you can easily deploy it to WebLogic.

Then you can start with the following URL:. The self-tuning mechanism will backfill if necessary. So how long does it take for them to become hogged?

Nobody including Google seemed to know. Trust me I did some research and asked plenty of colleagues about this. Here is the answer:. So interestingly hogging threads are detected right away! In my case it took about 2 seconds I had to hit reload once. Only the health runtime value is set to Warning but this will be cleared if the hogging thread conditions clears as shown below:. But which state has a thread to be in to be marked as stuck later?

So both states can become stuck. All of this is are reasonable usages likely to occur in the wild. You cannot cancel or kill any thread in Java. However, stuck threads automatically will disappear if the condition clears up which caused them to be marked as stuck e. In the WebLogic log file you will find three entries logging the stuck thread state after a while:.

So once the condition causing the stuck threads is cleared also the stuck threads will disappear again! Stuck threads are not stuck forever. Very good question. Do not use StuckThreadCount if the threads might be doing something useful and you cannot react on the situation anyway. The following posting shows how simple tools like ps, top and jcmd can track down the exact line of Java code causing a thread to use a high amount of CPU. Exactly the same StuckThreadForFree application is used as here.

Actually something I was talking about just a while ago at a customer site. Thanks to Mark you can download it. Let me know if you have another example — or if you come to other conclusions playing around with the app provided. Excellent post! Very thorough and up to date for WLS 12c. The app is also very useful for studying Stuck Threads.

Another way to create stuck threads I think, it would be to perform the following: Have my app deployed in WLS and connect my debugger. Set a breakpoint in somewhere in my app and let it there paused. This will also create a stuck thread the thread that is serving my app at the moment.

So I can simulate the behaviour of my WLS when my app is deployed and a stuck thread occurs. I appreciate your comment a lot! What you suggest is a great way to verify that the configured measures such as workmanager settings for a deployed app are working in fact.

Using a debugger is a nice idea.. First it is awesome article. Many Many Thanks for same. Can you please share us the code for StuckThreadForFree.

Really appreciate your feedback on this. Messages Message icon — Error Unable to access the selected application. Did you deploy on WebLogic 12c? It will only work with EJB 3. Also I added a download link for the whole Netbeans project so you can experiment yourself. A thread is flagged as hogger when it is running for a longer time than the average response time of all requests.

The definition makes a lot of sense IMHO. Do you have any reference for it? So a while ago…. The drawback: if you have a cpu intensive task like parsing a huge xml , WLS makes things worse lowering the thread priority. I appreciate your feedback, good that is helpful for you. StuckThread was written based on EJB3. If you are a developer you could download the Netbeans project and modify it yourself making blocking calls, less pretty but still working.

Thanks Frank for detailed information on the topic which is generally not discussed clearly in any documentation. This post solved the puzzle for us. Thanks Again. Keep Posting. I appreciate your kind words.

Glad that the posting was helpful. You need to modify some default Java values in these scripts to fit your environment and applications. See Specifying Heap Size Values for details about setting heap size options. The WebLogic Server configuration file config.

Tuning these parameters based on your system requirements rather than running with default settings can greatly improve both single-node performance and the scalability characteristics of an application. Within a WebLogic Server domain, the configuration file is located on the machine that hosts the Administration Server, and provides persistent storage of WebLogic MBean attribute values.

The Administration Server serves as a central point of contact for server instances and system administration tools. A domain may also include additional WebLogic Server instances called Managed Servers, which are used mainly for servicing applications.

When the Administration Server starts, it reads the domain configuration file and overrides the default attribute values of the administration MBeans with any attribute values found in the configuration file. Every time you change an attribute using the system administration tools using either the command-line interface or the Administration Console , its value is stored in the appropriate administration MBean and written to the configuration file.

Table lists the config. Table Performance-Related config. See Tuning Connection Backlog Buffering. See Caching Prepared and Callable Statements. You can indicate whether a domain is to be used in a development environment or a production environment. WebLogic Server uses different default values for various services depending on the type of environment you specify. Table lists the performance-related configuration parameters that differ when switching from development to production startup mode.

Execute Queue: ThreadCount. The tuning defaults discussed in throughout WebLogic Performance and Tuning Guide refer to the "development mode" defaults, which is the default startup mode when WebLogic Server is installed. For information on switching the startup mode from development to production, see Changing the Runtime Mode in the Administration Console Online Help.

For a complete listing of the differences between development and production startup modes, see the " Differences Between Configuration Startup Modes " section in Creating WebLogic Configurations Using the Configuration Wizard. Benchmarks show major performance improvements when you use native performance packs on machines that host WebLogic Server instances. Performance packs use a platform-optimized, native socket multiplexor to improve server performance. For example, the native socket reader multiplexor threads have their own execute queue and do not borrow threads from the default execute queue, which frees up default execute threads to do application work.

However, if you must use the pure-Java socket reader implementation for host machines, you can still improve the performance of socket communication by configuring the proper number of socket reader threads for each server instance and client machine. To see which supported platforms currently have performance packs available:.

The ensuing page contains tables of information for each supported WebLogic Server releases including service packs. Within each release table there is a "Performance Pack" entry that indicates whether a performance pack is "Included" in the release. The use of native performance packs are enabled by default in the config. You can also use the Administration Console to verify that performance packs are enabled:.

The value of the ThreadCount attribute of an ExecuteQueue element in the config. As work enters an instance of WebLogic Server, it is placed in an execute queue. This work is then assigned to a thread that does the work on it. Threads consume resources, so handle this attribute with care—you can degrade performance by increasing the value unnecessarily. By default, a new WebLogic Server instance is configured with a development mode execute queue, weblogic.

In addition, WebLogic Server provides two other pre-configured queues:. Unless you configure additional execute queues, and assign applications to them, Web applications and RMI objects use weblogic. Note: If native performance packs are not being used for your platform, you may need to tune the default number of execute queue threads and the percentage of threads that act as socket readers to achieve optimal performance.

Adding more threads to the default execute queue does not necessarily imply that you can process more work. Even if you add more threads, you are still limited by the power of your processor. Because threads consume memory, you can degrade performance by increasing the value of the ThreadCount attribute unnecessarily. A high execute thread count causes more memory to be used and increases context switching, which can degrade performance.

The value of the ThreadCount attribute depends very much on the type of work your application does. For example, if your client application is thin and does a lot of its work through remote invocation, that client application will spend more time connected — and thus will require a higher thread count — than a client application that does a lot of client-side processing. If you do not need to use more than 15 threads the development default or 25 threads the production default for your work, do not change the value of this attribute.

As a general rule, if your application makes database calls that take a long time to return, you will need more execute threads than an application that makes calls that are short and turn over very rapidly.

For the latter case, using a smaller number of execute threads could improve performance. To determine the ideal thread count for an execute queue, monitor the queue's throughput while all applications in the queue are operating at maximum load. Increase the number of threads in the queue and repeat the load test until you reach the optimal throughput for the queue.

At some point, increasing the number of threads will lead to enough context switching that the throughput for the queue begins to decrease. Note: The WebLogic Server Administration Console displays the cumulative throughput for all of a server's execute queues. To access this throughput value, follow steps in Modifying the Default Thread Count.

Table shows default scenarios for adjusting available threads in relation to the number of CPUs available in the WebLogic Server domain. These scenarios also assume that WebLogic Server is running under maximum load, and that all thread requests are satisfied by using the default execute queue.

If you configure additional execute queues and assign applications to specific queues, monitor results on a pool-by-pool basis. So how can I know and catch this Zombie process? Of course, but the how depends on what you are doing and with what tools Add a comment. Active Oldest Votes. Improve this answer. EduardoMaia EduardoMaia 4 4 silver badges 16 16 bronze badges. Sign up or log in Sign up using Google.

Sign up using Facebook. Sign up using Email and Password. Post as a guest Name.