WebLogic Threading Model

For Online Oracle Weblogic Admin Training, please contact through http://www.appsdbatraining.com

WebLogic Threading Model

•WebLogic Server is a multi-threaded java application that uses an internal component called an “Execute Thread” (which extends java.lang.Thread) to perform it’s work.
•Threads are created out of thread pools. Each thread pool is meant for specific purpose.

The important thread pools are:
•Thread Group: weblogic.socket.Muxer Defaults to 3 on Unix systems and 2 on Windows.Threads from this group are used for socket reading purpose.
•Thread Group : weblogic.health.CoreHealthMonitor CoreHealthService creates an instance of this thread to do periodic monitoring ofservers’ memory and state of its threads. It reports stuck threads.
•Thread Group : weblogic.admin.RMI
Threads from this group are used for communication between Admin and managed servers.
Eg: Deployment of application.
•Thread Group: weblogic.kernel.System
Threads from this group are used for weblogic internal activities like RJVM heartbeats, getting http state dump for JNDI updates in cluster.
•Thread Group : weblogic.admin.HTTP
Threads from this group are used for serving all console related requests.
•Thread Group: weblogic.kernel.Non-Blocking
Threads from this group are used for session replication activities.
•There are other threads created by JVM.
For Eg: in case of SUN JVM we can see:

“Signal Dispatcher” daemon prio=10 tid=0x009226e8 nid=0xc24 waiting on condition[0..0]
The Signal Dispatcher is responsible for forwarding native events like when user hits kill -3, this thread takes care of initiating the process of getting thread dumps.
•Thread Group: weblogic.kernel.default
The threads from this group are the main worker threads that does the real work.
These threads service requests to the application hosted on weblogic.
There are 15 threads by default. The number of execute threads can be modified through Admin console.



WebLogic Threading- Custom Queues

Custom thread queues are user defined.
The following are the two steps to achieve this.
1)Create a thread queue. This can be done from Admin Console.
2)Assign the created thread queue for an application. This is done by including the queue information in the application descriptor files.
For eg:
Weblogic Admin console (console.war) is a webapplication that has custom thread queue. If we see weblogic.xml of console.war we can see the custom queue definition as:


If we are creating a sample thread queue say “my-sample-queue”
To assign it our webApplication, just as these entries to weblogic.xml of our webApplication.


3)EJB (EJB interfaces, java libraries/classes)
Descriptor files:
4)RAR ( J2EE connector)
Descriptor files:
The applications can be deployed in archived format (EAR,WAR) or as exploded format. (Although we rarely see EJBs deployed in directory format)