Java does not support stopping threads anymore - From where did you get this information?
o how are actions like forced shutdown of managed servers implemented in weblogic, if there are stuck threads. - Via JMX.
Similarly you can also shutdown a datasource thread too even if it is stuck in a long running query. - You can stop the datasource.
We do not know much about the implementations of Weblogic threads. However, based on the documented and observed working, I guess that it implements an Observable pattern. The threads regularly report back that they're done with a task. And they're idle or ready to pick-up another task.
Weblogic isn't able to actually forcefully stop them. When they're active (not stuck) Weblogic can signal them to stop, to downsize the threadpool. But a thread can only do that when not stuck.
Datasources work differently, they're not threads but connections. And you can close a connection to the database. But weblogic would not do that by itself. Because that would mean that it would interfere with running code.
For instance, Weblogic might signal that the thread is Stuck, because it does not report back within the configured 10 minutes (600s). However, it might just wait for a long running database query (maybe poorly written) that eventually gets back with a result. Then a Stuck thread becomes unstuck. So even when Weblogic would be able to forcefully kill a thread, that would mean that Weblogic would break long-running code. Weblogic can't know what the thread is doing.
What Weblogic can do is keep track on the available threads. And if too many threads get stuck, and due to that it has too little threads left to do it's work and pick up new requests, it can kill itself or have the nodemanager do that by requesting the OS to do a kill.
Also using Workmanagers Weblogic can restrain certain applications and modules to limit the delegated threads, keeping enough threads for other applications and modules. When you define workmanagers on applications you can prevent that the particular modules 'eat up' all resources for other applications.
Hope this clarifies.
Java ( during 1.1 ) used to have a Thread.stop() method, which has been deprecated long ago.
But currently only has interrupt(), which the receiving thread has to honour and volunteer to abort.
JMX does not allow the thread to be killed either. ( JMX is just a mean to get inside the JVM )
Im not trying to solve any specific design problem - Im merely wondering how WL could be doing these 2 tasks
Yes there is a thread pool ( very akin to
Executors.newFixedThreadPool I think )
But however, if you do a force shutdown on the managed server, all threads are thrown out, followed by some shutdown routines executed.
( I suspect that did not kill the threads. Instead, they ran the shutdown routines and then just killed the JVM PID )
In the case of database, if it is stuck on an I/O system call, there is no way to kill it. Yet DS->Control->Suspecd has a 'Force Suspend'
( I suspect that Wl allows the stuck Datasource object to go, orphan, ( along with its thread ) and then merely creates a new datasource object inside the pool )
A java JVM is an OS Process. Threads are sort of execution sub-processes within the OS process. So killing or ending the OS process will kill the threads.
For datasources it is different: those aren't actual threads. A datasource has a connection pool with database connections. They keep an open connection to a database. Those connections can just be closed, which will cause the database to cleanup the user-process that handles the database side of the connection.
Database connections aren't tied to a thread. A thread borrows a connection. When a connection dies during execution of a thread, the application code that is executed by the thread should be written as robust as to be able to handle connection exceptions. It's the resposibility of the application developer to take care of that. It might unstuck the thread by the way, when the application code get's to handle the exception.
So are you saying that when you 'Force Suspend' a DB connection, which is being used by an application thread and which is stuck in a DB call, another weblogic system thread could be closing the connection object being used ?
....which is plausible
More or less. The console and WLST support are also applications in Weblogic. So requests to those are supposedly handled by threads as well. Which is supported by the observation that if your system is unresponsive due to stuck threads, also console, em, WLST, nodemanager are unable to get to the server. And then nodemanager can ask OS to kill the JVM.
Amongst worker threads in the threadpool Weblogic also uses system/internal threads to do internal work. Think of (probably) Diagnostic Framework handling, like policies and actions.
But the Datasource is represented by a Runtime MBean. And suspend/close/reset, etc. are methods on that MBean, which can be called through a wlst command or console.
But the Datasource or connections aren't threads by itself, they are runtime objects that can be called through application code executed by/within the threads.