Kill Execute Thread

Is there a way to kill specific Execute Threads. We are in a situation when an
MDB would not acknowledge specific messages and those MDBs(which run on default
execute queue) will not terminate. We would like to kill those threads when we
want to undeploy the app. IF there are MDBs running on other threads, then the
app would not end gracefully. See post
http://newsgroups.bea.com/cgi-bin/dnewsweb?utag=&group=weblogic.developer.interest.jms&xrelated=10750&cmd_thread_next.x=45&cmd_thread_next.y=11
So the question: Is there a way to kill specific execute threads thru JMX or some
other way?
Thanks
Raj

What do you mean by "executes a script"? Is this execing a shell or is it just running some Java code?
You can't kill a Thread if it doesn't want to be killed. The deprecated Thread.stop method will atempt to cause an asynchronous ThreadDeath exception in the thread but this is very dangerous as it can leave shared objects - including system library objects - in an unstable and unusable state.
The preferred mechanism is cooperative termination whereby you use the Thread.interrupt method to indicate to the target thread that it should cease what it is doing, when it is safe to do so. The target thread must be responsive to interrupt requests either by directly checking Thread.interrupted, or by using methods that are themselves responsive to interrupts (typically blocking methods that will throw InterruptedException if interrupted). Some blocking methods (mainly IO operations) won't respond to interrupt, nor does the acquisition of a monitor lock, so there are never any guarantees. If the thread can stuck in an "endless loop" then something in that loop needs to check for interrupts.

Similar Messages

How to Kill Specific Execute Threads

Hi.
Through our application server, we noticed that there were some memory issues
where the memory usage would rapidly increase from ~ 15Mb to the max heap size.
Issuing a few thread dumps, we realized that there was a specific thread that
was churning. This was b/c someone sent a large request in that generated a lot
of data.
Anyways, since we couldn't bounce the weblogic server, we had to wait until the
request ended. Since we know the specific thread that was assigned to that job,
is there a way to kill the request associated with a specific execute thread and
reallocate back to the thread pool? We're running weblogic 6.1sp4. I think the
executequeueruntime bean just gives me back the current configuration of the all
the threads in the specific queue, which doesn't help me here.
Thanks.
--Selena

Selena,
how about get the ExecuteQueueRuntimeMBean and get all the execute
threads (getExecuteThreads() which returns an array of ExecuteThreads )
and since you know the thread id that is causing the bottleneck, you
could kill that thread.
thanks,
-satya
Selena wrote:
Hi.
Through our application server, we noticed that there were some memory issues
where the memory usage would rapidly increase from ~ 15Mb to the max heap size.
Issuing a few thread dumps, we realized that there was a specific thread that
was churning. This was b/c someone sent a large request in that generated a lot
of data.
Anyways, since we couldn't bounce the weblogic server, we had to wait until the
request ended. Since we know the specific thread that was assigned to that job,
is there a way to kill the request associated with a specific execute thread and
reallocate back to the thread pool? We're running weblogic 6.1sp4. I think the
executequeueruntime bean just gives me back the current configuration of the all
the threads in the specific queue, which doesn't help me here.
Thanks.
--Selena

Clearing a Stuck Execute Thread

HI.
If you get a stuck execute thread, is there anyway of clearing it or rolling it back so the action (a POST in this case) can be repeated again?
STUCK] ExecuteThread: '16' for queue: 'weblogic.kernel.Default (self-tuning)'
684959
weblogic.servlet.internal.ServletRequestImpl@da2109[ POST /ols/uds/request HTTP/1.0 Accept: image/gif, image/x-xbitmap,
image/jpeg, image/pjpeg, application/x-shockwave-flash, application/vnd.ms-excel, application/vnd.ms-powerpoint,
application/msword, application/xaml+xml, application/vnd.ms-xpsdocument, application/x-ms-xbap,
application/x-ms-application, */* Referer: https://www.workcoverqld.com.au/ols/uds/file Accept-Language: en-au
Content-Type: application/x-www-form-urlencoded UA-CPU: x86 User-Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT
5.1; .NET CLR 2.0.50727; .NET CLR 3.0.04506.30; .NET CLR 3.0.4506.2152; .NET CLR 3.5.30729) Content-Length: 260 Pragma:
no-cache Cookie: JSESSIONID=Tsh3LLqRZrn0pYf4hdyrBbtLTxWf2sVg2Q8LBLgYpvrTThy9LYlJ!1280830650 X-Forwarded-For:
202.158.241.132 Connection: Keep-Alive Proxy-Client-IP: 202.158.241.132 X-WebLogic-KeepAliveSecs: 25
X-WebLogic-Request-ClusterInfo: true x-weblogic-cluster-hash: eu0SzdBVUqV5a6fkg3X2d1IDltA ]

Hi,
We can get more info about execute threads by getting thread dumps. Below are few ways to get
1. From weblogic admin console. Servers --> Monitoring --> Performance --> Dump Thread.
2. On the unix box enter the command "kill -3 <pid>".
3. Using WLST
java weblogic.WLST
>connect('<adminUsername>','<adminPassword>','<t3://adminServerUrl:port>')
>threadDump('true','VASLog.txt','<ServerName>')
>exit()
4. Using welogic.Admin command tool
java weblogic.Admin -adminurl t3://<adminServer>:<port> -username <adminUsername> -password <adminPassword> THREAD_DUMP
Except for point 3, all the output is written to "<ManagedServerLog>.out" file.
Thanks.
Vijay Bheemineni.

Killing a Thread

In recent versions of the JDK they deprecated the stop() and destroy() methods. They did so because those methods can kill a thread in a "dirty" way. The replacement approach is to have a while(isRunning){} loop in the run() method and to set isRunning to false via a call to another method.
I have a scenario that can be described as follows (taking some liberties with syntax):
public void run(){
while(isRunning){
JobInterface job = ... code to instantiate the job via reflection.
job.execute();
isRunning = false;
Here, although the interface is standard, the job is one of many possible applications written by other people and without access to their source code. The JobInterface is already defined and there are many applications already in production that use it - in other ways we can't expect to change the code of the reflected jobs. Further, setting isRunning to false while the job is executing its execute() method (possibly for hours) isn't going to help.
So the question here is, how to kill a thread like this one... while it is still waiting for job.execute() to end?

bmelloni wrote:
I only need the forced thread stop for those jobs that cannot be modified to comply with the above. At that point whatever consequences there are for those jobs will have to be accepted. If resources (i.e.: database) are left in messed up states... tough. It will have to be handled then (and maybe it will give incentive to make those black-box jobs compliant).I doubt it. Unless someone quite high-up is informed, these things are often shelved until something breaks. My suggestion would be to put your (our?) concerns in writing, and make sure you get a reply in kind from your management before you do anything. Once the finger-pointing starts, it's usually the sharp end that suffers.
But we aren't even planning to use this capability to stop threads unless our server is about to crash - in which case the consequences would have been the same.Better make sure it's VERY difficult to do accidentally then.
In other words, don't worry... we are not stupid.I don't think anyone said stupid...Naive, maybe.
Winston

Reclaiming stuck execute threads

Does anyone out there know of a setting in WLS 7 where you can tell it to reclaim
an execute thread that has been stuck for a while? There are settings to detect
stuck threads, but I would like it to reclaim (kill stuck one and create a new
one and add back to execute queue) that stuck thread after a set amount of time.
Will it already do this on its own; am I just not waiting long enough?

Hi Chris,
"Chris" <[email protected]> wrote in message
news:3eb143e6$[email protected]..
Does anyone out there know of a setting in WLS 7 where you can tell it toreclaim
an execute thread that has been stuck for a while? There are settings todetect
stuck threads, but I would like it to reclaim (kill stuck one and create anew
one and add back to execute queue) that stuck thread after a set amount oftime.
In Java there is no way to "kill" a stuck thread, and there is a good
reason for this.
The feature you are taking about is for diadnistic purposes
and should be used as such.
Will it already do this on its own; am I just not waiting long enough?If it's really stuck, you have to get a thread dump and find out
why thread stuck. You can get a thread dump by pressing
<Ctrl+Break> in Widows shell or sending kill -3 to the server
process under Unix.
Regards,
Slava Imeshev

Alternative to WebLogic 8.1 Execute thread Qs in Websphere 6.1

Hi All,
We are in the process of migrating from WebLogic 8.1 to WAS 6.1. We have few application in WebLogic that use custom execute threads so that trafic is moved to user defined thread instead of default thread pool. This is done in weblogic using dispatch-policy tag under weblogic.xml.
I appreciate if someone could help me understand the alternative of doing same thing in WebSphere 6.1.
I was going thru some site searching and came across Work Manager that does the same thing which is new to me but does similar job.
Thanks in advance

Hi All,
We are in the process of migrating from WebLogic 8.1 to WAS 6.1. We have few application in WebLogic that use custom execute threads so that trafic is moved to user defined thread instead of default thread pool. This is done in weblogic using dispatch-policy tag under weblogic.xml.
I appreciate if someone could help me understand the alternative of doing same thing in WebSphere 6.1.
I was going thru some site searching and came across Work Manager that does the same thing which is new to me but does similar job.
Thanks in advance

How do you modify the default Execute thread count in Weblogic Server 9.2?

How do you modify the default Execute thread count in Weblogic Server 9.2?
How can you tune the starting number of weblogic.ExecuteThread on server startup and/or set minimum number?
Is there an option from the console?
Please let me know.
Thanks

Self tuning will automatically manage the threads but however you can still control the min and max by adding the min and max values for each instance either directly adding in config.xml or through JVM settings
1) Modifying the config.xml
Just add the following line(s) to each server definition :
<server>
<name>AdminServer</name>
<self-tuning-thread-pool-size-min>100</self-tuning-thread-pool-size-min>
<self-tuning-thread-pool-size-max>200</self-tuning-thread-pool-size-max>
</server>
2) Adding some JVM parameters
It's safer the following way :
add the following option in your command line : -Dweblogic.threadpool.MinPoolSize=100
Regards
RR

How can I kill a thread.

I have read the many threads about killing a thread but they dont answer the question I need to know.
In class#1 I have the following snipet of code:
for (int i=0; i < docs.size(); i++)
    try {
        boolean blncompleted = false;
     Map object = null;
        OntologyCreatorThread ontThread = new OntologyCreatorThread ();
     ontThread.start();
     ontThread.join(15000); // Allow thread to process for up to 15 seconds.
     // If thread is still running, kill the thread. I dont care about
     // clean up since its only using memory and cpu, no DB is ever touched.
     if (ontThread.getState().toString().equals("RUNNABLE")){
         ontThread.interrupt();
            ontThread.stop();
            // set flag to false
         blncompleted = false;
        else {
            // set flag to false and do a ton of other processing.
         blncompleted = false;
         object = ontThread.getObject();
    catch (Exception Ex){
        Ex.printStackTrace();
In my thread I have the following:
public class OntologyCreatorThread extends Thread {
    Map object = null;
    public OntologyCreatorThread(){
    public void run() {
       try {
         // The line below takes forever to run sometimes.
         object = functionCallToApi(stringOfText);
    public Map getObject() {
     return objects;
If the thread takes to long to run I just want to kill it.
I have tried interupt and stop and both dont work. Inside the run method of the thread I call an external API
which I pass a string of text. I can not get into that code because its from a Off the shelf product that we dont
have the code to. If the call in the run method takes to long I want to just kill this thread in the main class(#1).
No matter what I do I cant get the damn thing to stop.
The line below takes forever to run.
         object = functionCallToApi(stringOfText);
Putting it in a while loop wont solve this problem because the processing is still taking place in the call to the api.
Thanks in advanceMessage was edited by:
Storm897

Couple of things to consider:
1. Note that Thread.interrupted() and t.isInterrupted() are very different methods. The former clears the interrupted status so that a subsequent call will return false. The latter does not affect the interrupt status on the thread.
2. If your "atomic step one" catches an Exception, then you might be swallowing an InterruptedException. Basically the rule when a Thread is interrupted is that if it is in a blocking call, an InterruptedException is thrown. Otherwise, isInterrupted is set to true. So if you have blocking (I/O) calls in "atomic step one" and you're catching Exception, then it might be that the InterruptedException goes completely unnoticed.
3. If "atomic step one" takes a long time and you really want to abort the thread instantly, then you need some kind of method for doing so--you need to program in safe "stopping points". For example:
public class Helper implements Runnable {
   private boolean _continue = true;
   public void cancel() {
      _continue = false;
   public void run() {
      _continue = true;
      try {
         // Do something until in safe/stable state
         if(!_continue) return;
         // Do something until in safe/stable state
         if(!_continue) return;
         while(_continue) {
             // process single record in large data set
             // Safe to stop at the end of each loop
         if(!_continue) return;
         // Do something else . . . etc.
      } catch(InterruptedException ie) {
         _continue = false; // Unnecessary, but here for illustration
}Casual programmers often don't care whether the thread stops safely or not, but it really is important especially if you are in the middle of some kind of transaction. That's why destroy(), cancel() et al are deprecated.

Identifying Execute Threads as Socket Readers

Hi All,
Preface: I am trying to identify at any given instance the percentage of
socket reader threads that are in use - this will help me to identify when
all threads are in use and unable to service user requests. Thus my goal is
to identify threads that are socket readers and whether they are active or
idle.
Through JMX I can obtain an instance of each
weblogic.management.runtime.ExecuteThread, which lists the same information
that you see in the console if you drill down to the thread level, for
example:
mydomain> Servers> myserver> Active Execute Queues> default> Execute Threads
That information includes:
- thread number
- total requests
- last request
- current request
- transaction
- user
- is the thread idle?
Now my question is from this information can you identify which of these
threads are being used as socket readers?
Here are some excerpts from my JMX calls:
Name: ExecuteThread: '0' for queue: 'default'
Execute Queue Runtime Name: default
Current Request: null
Last Request: Http Request: /bookstore/en/authors/showauthors.jsp
User: null
Is Idle?: true
Name: ExecuteThread: '15' for queue: 'default'
Execute Queue Runtime Name:default
Current Request: null
Last Request: Scheduled Trigger
User: null
Is Idle?: true
Name: ExecuteThread: '26' for queue: 'default'
Execute Queue Runtime Name:default
Current Request: null
Last Request: ListenRequest for a new connection on: 'Socket
addr=127.0.0.1,port=2061,localport=7001]'
User: null
Is Idle?: true
Name: ExecuteThread: '59' for queue: 'default'
Execute Queue Runtime Name:default
Current Request: Socket Reader Request
Last Request:
weblogic.transaction.internal.ServerCoordinatorDescriptor$2@138786
User: null
Is Idle?: false
It would appear that the "ListenRequest" last request would identify a
socket reader, only I have 60 threads in my default execute queue with 70%
dedicated to socket readers and the number of threads that say their last
request was "ListenRequest ..." is only 5.. Furthermore there is only one
"Socket Reader Request" identified thread.
Are threads identified as socket readers permanently or constantly reused
for whatever purpose is required (with a cap of use based off of the socket
reader perspective)?
Thanks in advance for your help!
Steve

Hi Achhi,
Socket Reader Threads are the Threads which are responsible for reading the incoming request data. We can divide the Socket reader threads in two categories:
Pure Java Socket Reqders: The pure-Java socket reader implementation, where the socket reader threads continually poll all opened sockets to determine whether they contain data to be read, even if the sockets have no data to read. (From Performance Point This is Not Good that the Sockets will be in Opened Mode even if there is no Data to read)
Native Socket Readers: (These are the Dafault Socket Readers) The native IP socket reader provided by the host machine's operating system, where the socket reader threads target only active sockets that contain data to be read. Native socket readers never poll sockets because they are immediately notified when a socket needs to be serviced. For Better Performance You should always prefer using Native Socket Readers.
To Enable Native Socket Readers You can Login to AdminConsole--->Servers ---><SERVER_NAME>--->configuration (Tab)--->Tuning (SubTab)---> "Enable Native IO" (This checkbox must be checked)
Still If you want to use the Java Socket Readers .... still you can improve the performance of socket communication by configuring the proper number of socket reader threads for each server instance. For best performance, the number of socket reader threads in WebLogic Server should equal the potential maximum number of opened sockets.
Thanks
Jay SenSharma
http://weblogic-wonders.com/weblogic (WebLogic Wonders Are here)

Killing a thread easily?

Hello, I'm working with a thread class that looks like this:public void run() {
     while (true) {
          Socket client = aServerSocket.accept();
          // do stuff
}The problem is kind of obvious, as it is, it never stops unless you kill the VM, eventually leading to dozens of threads. Even if I changed the loop variable, the thread would still hang around while accept() blocked for input. I want to kill it when I know it's useless. My first attempt was:     while (!Thread.interrupted()) {and then calling interrupt() on the thread - oops! - serversockets aren't interruptable, so the thread still never stopped. I was going to come here and post then, but I went back and read the api for server sockets again, and found that calling close() on the socket will interrupt the blocking accept(). So:     while (!aServerSocket.isClosed()) {Unfortunately, I'm not sure if that actually works, or not, because my app which used to take up < 1% of CPU time when running was now taking more than 50%, so I shut it down - at least when there are lots of threads, they are all sleeping and don't eat the cpu :(
Does anyone have any suggestions on how to stop threads ?

A: Killing a thread easily?

ejp: I'm not sure what you're referring to, but from the ServerSocket api:
"close() : Closes this socket. Any thread currently blocked in accept() will throw a SocketException."
There are other things in the 'do stuff' part of the loop that can throw exceptions, but I don't want to break out of the loop. I omitted the try around 'accept' and 'do stuff' for simplicity in my original diagram. I tried rearranging my try statements like so:
try {
     while(true) {
          Socket client = aServerSocket.accept();
          try {
               // do stuff
          } catch ()
} catch ()So that if the accept call threw an exception, it would drop out of the while loop. Unfortunately, when I tried running this the program took up >25 % of my CPU time to run, instead of < 1 % as usual, like my third try above.
hiwa: Sorry I didn't explain more clearly. Several of these threads are being spawned to listen to multiple sockets. Sometimes the connection gets dropped, due to lag or internal reasons, and it reconnects on a new socket with a new thread, but the old socket and thread are still hanging around because it's stuck in the while(true) loop and accept blocks indefinately.

Max no of execute threads in 4.5

Hi,
We have set the no of execute threads in 4.5.1 to >700. During start up of
the weblogic server, we get the following message:
!!!!!!!!!!!!!!!!!!!!!Property
weblogic.system.executeThreadCount has value: 775 > max: 400 setting value
to 400
Does WebLogic not allow the no of execute threads to be more than 400?
Thanks
Gaurav

Thanks for that info. That was very helpful.
Gaurav
Wei Guan <[email protected]> wrote in message
news:[email protected]...
400 is a hard-coded upper limit. There is no way you can change it.
From my understanding, ExecuteThreads => UserConnections + ConnPoolSize isa
confusing "rules of thumb".
Number of threads depends on the average request processing time, average
waiting time that your users can accept and average concurrent users. For
Internet application, nobody wants to wait, so, we can assume average
waiting time equals average processing time (this is the mininum waiting
time).
In order to find out how many threads you need, first find out the average
reqeust processing time of your systems. Secondly, find out how many
concurrent users you will have, in your case, it is 100. Keep in mind not
all users send requests to WLAS at the same time. There is a ratio ofnumber
of concurrent users to number of concurrent requests within the average
request processing time. Statistically, the higher the number ofconcurrent
users, the higher this ratio. Normally, this ratio can range from 1 to 20
(Sorry, I do not have any research paper, however, this is a typicalrandom
processing problem). If you have a very powerful machines and the average
processing time is very low, this ratio can be even higher (for example,
your average processing time is 1/2 seconds, and user waiting time is 2
seconds). Threads likes employees in MacDonnald. The number of customersin
MacDonnald likes concurrent users. Customers who actually waiting to be
served is like current requests. If the number of employees equals the
number of customers in MacDonnald, you will see MacDonnald stocks willlike
trash within couple of days. If the number of employees equals the numberof
customers waiting to be served, you will see the stocks will be trashwithin
couple weeks.
Since 100 is a medium size number, let's take 4 as the ratio, 100/4 = 25.
So,
there might be 25 concurrent requests within your average requestprocessing
time. How many threads you need to process 25 concurrent requests? 25!
Start with 25 and monitor weblogic server. If CPU utilization is low andthe
number of requests in WLAS request queue is low, decrease this number. If
CPU utilization is very high and the number of requests in WLAS requests
queue is high, increase this number. Tuning WLAS needs patience and
carefulness.
The default of threads is 15. Normally, WebLogic suggested use 15 to 60
threads.
Large number of threads will not buy you anything. It simply creates lotsof
idle threads and wastes systems resources to do context switching. Those
threads like extra employees in MacDonnald. MacDonnald has to pay them$$$.
One of reason why private companies are more efficient and profitable than
government is that private companies try their best to increase that
"ratio".
I guess, "400" by WebLogic is a way that WebLogic prevents your fromrunning
your WebLogic Server likes a state-owned enterprise where employees can
enjoy coffees at their office most of the time. I guessed :-).
You just have 100 users, where 600 connections are coming from???
My 2 cents.
Cheers - Wei
Gaurav Khanna <[email protected]> wrote in message
news:[email protected]...
Yep,
We have a 4 processor machine and 600 connections and 100 concurrentusers.
BTW, is 400 the upper limit and is that specified by WebLogic or the OS?
Thanks
Gaurav
Srikant Subramaniam <[email protected]> wrote in message
news:[email protected]...
Yes, there is an upper limit (as you discovered)! Any reason why you
would
want to have 700 executeThreads?
Srikant.
Gaurav Khanna wrote:
Hi,
We have set the no of execute threads in 4.5.1 to >700. During start
up
of
the weblogic server, we get the following message:
!!!!!!!!!!!!!!!!!!!!!Property
weblogic.system.executeThreadCount has value: 775 > max: 400 settingvalue
to 400
Does WebLogic not allow the no of execute threads to be more than
400?
>>>>
Thanks
Gaurav

Query Regarding Execute Thread Count

Hi,
My understanding of Execute Thread Count is the threads which are assigned to service
requests coming to Weblogic Server.
In our current architecture a request for generating report is directed to EJB method
which makes a call to another Server (Report Server for executing reports), the report
Server in turn calls the EJB residing on Weblogic Server for getting the data.
So, is my assumption correct that with our current architecture we are limited to
concurrency of Execute Thread Count -1. (Every request for report will consume 2
Excute threads, and others will have to wait till the first request gets completed
and 2 threads are freed).
I also read from the postings that Weblogic takes some of the threads, so it actually
will be limited to (Execute thread count - Weblogic Held- 1).
Please corect me if I am wrong.
Thanks and Regards
Rashmi

Hi,
Thanks very much for the suggestion. I tried, and it is using 2 Execute Threads.
Thanks
Rashmi
"Dave Martin" <[email protected]> wrote:
>
Rashmi:
If you are interested in answering the question rigorously, why not just
throw a
fake exception along both the report generation path and the runReport method
of
the ReportServer, then record their stack traces to a file for comparison?
From the sounds of it, your app wants to make the actual report generation
asynchronous
from the post of the reporting request. If they're really asynchronous,
then your
ReportServer must have some kind of blocking queue that will "wake up" when
it has
work to be done. Depending on how you implemented this, your runReport
method may
not be running a WebLogic execute thread at all.
Seems to me that you should be thinking of this as consuming one execute
thread regardless.
Even if the two pieces of work are asynchronous, the first thread finished
its work
at the point that it posts to the second thread (at least, per your description).
So at any one time, at max one execute thread is being consumed per request.
But capture the stack traces and have a look for yourself.
Dave Martin
"Rashmi S" <[email protected]> wrote:
Hi,
Thanks for your reply.The reason why I say 2 threads will be consumed is
as follows
1. First execute thread will be used for the request to Weblogic Server
to run the
report originating from a client.
2. Now, within the ReportServices EJB there is a call to Report Serverto
run the
report. The running of report is done on the Report Server which is ona
separate
m/c. Within the runReport method of the Report Server ,the data is fetched
for the
report by making a context look-up of another session EJB which fetches
the data.
So, the second Execute thread will be consumed for executing the EJB that
fetches
the data.
Am I correct?
Thanks and Regards
Rashmi
"Cameron Purdy" <[email protected]> wrote:
Incoming requests (from outside the server) use one thread for the duration
of their processing. Previous to their processing they are queued until
a
thread is available. So you would use one thead per concurrent request,
not
two. Otherwise, it sounds right.
Peace,
Cameron Purdy
Tangosol, Inc.
Clustering Weblogic? You're either using Coherence, or you should be!
Download a Tangosol Coherence eval today at http://www.tangosol.com/
"Rashmi S" <[email protected]> wrote in message
news:[email protected]...
Hi,
My understanding of Execute Thread Count is the threads which are assignedto service
requests coming to Weblogic Server.
In our current architecture a request for generating report is directedto EJB method
which makes a call to another Server (Report Server for executingreports), the report
Server in turn calls the EJB residing on Weblogic Server for getting
the
data.
So, is my assumption correct that with our current architecture we arelimited to
concurrency of Execute Thread Count -1. (Every request for report willconsume 2
Excute threads, and others will have to wait till the first request
gets
completed
and 2 threads are freed).
I also read from the postings that Weblogic takes some of the threads,so
it actually
will be limited to (Execute thread count - Weblogic Held- 1).
Please corect me if I am wrong.
Thanks and Regards
Rashmi

Log of execute thread pool status

hi guys
We are performing some performance analysis on a application and would
like to log the status of the execute thread pool periodically to a
log file.
The performance tests run for a extended period of time and hence
console is not proving to be effective in monitoring the behaviour
over a long period of time.
What other alternatives exist if I want to do this.
Thanks for your time
anand

thanks guys,
I found an answer in one of rob wollens old post.
http://dev2dev.bea.com/resourcelibrary/utilitiestools/index.jsp
Sorry for posting without doing a little research
~anand

Configuring Execute Thread Count

Hi,
I am working on a webapp thats using Weblogic 8.1 (SP2) as the application server.
The admin server for Weblogic currently provides 2 execute threads as default.
However I was wondering if I can configure the admin server for a higher number
of execute threads.
I have the following questions:
1.> Does configuring the number of threads for the admin sever provide any additional
value? has any one come across a big application where more than 2 execute threads
are required for the admin server?
2.> If yes, is it possible to configure the number of execute threads for the
admin server? I did some search on the bea website and didnt find anything that
explicitly says that the property is configurable. Is this true?
3.> If it is configurable, then how do we go about setting it up?
If anyone has worked around this and can provide me with any information or references,
that would be great.
Thanks

          Sriram,
          Take a look at the following URL for setting the thread count in WLS 6.1
          http://edocs.bea.com/wls/docs61/perform/WLSTuning.html#1112343
          Chuck Nelson
          Developer Relations Engineer
          BEA Technical Support

Best way to stop or kill a thread

hi what would say is the best way to kill a thread in this situation.
1. I have 200 threads
2. Each Thread has a reference stored in a hashtable example;
for( int i=0; i<200; i++){
Thread t = new exThread(i);
hashtable.put(Integer(i) , t );
t.start();
each thread is running in an infinite while loop.
now what would you say is the best way to kill the thread from this parent class.
One thought of mine is to access get the reference and call stop.
example;
Thread tRef = hashtable.get(Integer(100));
tRef.stop();
In the stop method i would clear up whatever it was doing - release resources properly and - when it goes out of the stop scope , i'm guessing it would be destroyed.
Any thoughts or other recommendations ?
Stev

Limeybrit is correct....the way Sun recommends (and which I use) is a boolean at the top of your runnable code. If false, you simply return and don't hit any of the other code in the runnable method.
At the end of your run process, you simply set your Thread to null and wait for the garbage collector to clean up.

Kill Execute Thread

Similar Messages

Maybe you are looking for