Wls10mp1  thread pool queue length

This is under admin console -- server -- threads -- monitoring.
This field : QueueLength has a -ve value some times.
Doc states :
QueueLength
The number of pending requests in the priority queue. This is the total of internal system requests and user requests.
Console also shows penging user request count as 0.
What could cause it to be -ve ?
Thanx,

Yesterday an Oracle Consultant acknowlegded that it is a bug. There was a patch issued for Negative count in the JMS queue count and now this. Thanks for the reply by the way.

Similar Messages

  • Thread Count Queue Length in Negative and Too many standby Thread

    We are using Weblogic server 9.2.2 with 1 admin server and 4 managed server . Currently in one of the servers I could observe that there are around 77 standby threads.
    Home > Summary of Servers > server1 > Monitoring > Threads > Self-Tuning Thread Pool
    I could see that the "queue length" is negative (-138) and self tuning standby thread count is 77. Large number of threads STANDBY thread persists during the busy time of the business hours where as other servers are fully utilized.
    Is it normal to have negative queue length and so many STANDBY threads? As for JMS queue negative oracle had already acknowledged that it is a bug. Thanks.
    Edited by: 855849 on May 1, 2011 7:19 AM
    Edited by: SilverHawk on May 12, 2011 8:12 AM

    Yesterday an Oracle Consultant acknowlegded that it is a bug. There was a patch issued for Negative count in the JMS queue count and now this. Thanks for the reply by the way.

  • Capturing/dumping active thread, queue length and throughput to a file

    Hi,
    I would like to capture active thread information, queue length, and throughput
    information to a file for later analysis. This would be similar to setting the
    verbosegc flag at the java startup to dump the heap space memory usage.
    Is there a way of doing this?

    Just like with heap info, you can use weblogic.Admin GET functionality to query
    WebLogic runtime information.
    To see which bean types you need to query and what properties are available you
    can deploy these 2 jsp's on your weblogic:
    http://dima.dhs.org/misc/listMBeans.jsp
    http://dima.dhs.org/misc/showMBean.jsp
    and point your browser to listMBeans.jsp - the rest is self-explanatory.
    Mark Officer <[email protected]> wrote:
    Hi,
    I would like to capture active thread information, queue length, and throughput
    information to a file for later analysis. This would be similar to setting the
    verbosegc flag at the java startup to dump the heap space memory usage.
    Is there a way of doing this?--
    Dimitri

  • Thread pool throws reject exceptions even though the queue is not full

    Hi. I am using org.springframework.scheduling.concurrent.ThreadPo olTaskExecutor which is based on java
    java.util.concurrent.ThreadPoolExecutor
    with a enviornment under load.
    I see on some cases, that this thread pool throws tasks with reject exception
    even though the queue size is 0.
    According to the documentation, this thread pool should increase the pool size to core size and then wait untill all queue is full to create new threads.
    this is not what happends. for some reason the queue is not filled but exceptions are thrown.
    Any ideas why this can happen?

    This is the stack trace:
    taskExecutorStats-1 2010-04-27 11:01:43,324 ERROR [com.expand.expandview.infrastructure.task_executor] TaskExecutorController: RejectedExecutionException exception in thread: 18790970, failed on thread pool: [email protected]544f07, to run logic: com.expand.expandview.infrastructure.logics.DispatchLogicsProviderLogic
    org.springframework.core.task.TaskRejectedException: Executor [java.util.concurrent.ThreadPoolExecutor@dd9007] did not accept task: com.expand.expandview.infrastructure.task_executor.TaskExecuterController$1@141f728; nested exception is java.util.concurrent.RejectedExecutionException
         at org.springframework.scheduling.concurrent.ThreadPoolTaskExecutor.execute(ThreadPoolTaskExecutor.java:305)
         at com.expand.expandview.infrastructure.task_executor.TaskExecuterController.operate(TaskExecuterController.java:68)
         at com.expand.expandview.infrastructure.proxies.DataProxy.callLogic(DataProxy.java:131)
         at com.expand.expandview.infrastructure.proxies.DataProxy.operate(DataProxy.java:109)
         at com.expand.expandview.infrastructure.logics.AbstractLogic.operate(AbstractLogic.java:455)
         at com.expand.expandview.server.app.logics.stats.StatsPersisterSingleChunkLogic.persistSlots(StatsPersisterSingleChunkLogic.java:362)
         at com.expand.expandview.server.app.logics.stats.StatsPersisterSingleChunkLogic.doLogic(StatsPersisterSingleChunkLogic.java:132)
         at com.expand.expandview.infrastructure.logics.AbstractLogic.execute(AbstractLogic.java:98)
         at com.expand.expandview.server.app.logics.ApplicationLogic.execute(ApplicationLogic.java:79)
         at com.expand.expandview.infrastructure.task_executor.TaskExecuterControllerDirect.operate(TaskExecuterControllerDirect.java:33)
         at com.expand.expandview.infrastructure.proxies.LogicProxy.service(LogicProxy.java:62)
         at com.expand.expandview.infrastructure.logics.AbstractLogic.service(AbstractLogic.java:477)
         at com.expand.expandview.server.app.logics.stats.StatsPersisterLogic.persist(StatsPersisterLogic.java:48)
         at com.expand.expandview.server.app.logics.stats.StatsPersisterLogic.doLogic(StatsPersisterLogic.java:19)
         at com.expand.expandview.infrastructure.logics.AbstractLogic.execute(AbstractLogic.java:98)
         at com.expand.expandview.server.app.logics.ApplicationLogic.execute(ApplicationLogic.java:79)
         at com.expand.expandview.infrastructure.task_executor.TaskExecuterController$1.run(TaskExecuterController.java:80)
         at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
         at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
         at java.lang.Thread.run(Thread.java:619)
    Caused by: java.util.concurrent.RejectedExecutionException
         at java.util.concurrent.ThreadPoolExecutor$AbortPolicy.rejectedExecution(ThreadPoolExecutor.java:1760)
         at java.util.concurrent.ThreadPoolExecutor.reject(ThreadPoolExecutor.java:767)
         at java.util.concurrent.ThreadPoolExecutor.execute(ThreadPoolExecutor.java:658)
         at org.springframework.scheduling.concurrent.ThreadPoolTaskExecutor.execute(ThreadPoolTaskExecutor.java:302)
         ... 19 more

  • Thread pools for execute queues

    We've set up thread pools for several execute queues dedicated to high-load servlets
    in our application. Once in a while, we get into a condition in which none of
    these threads are available and then the threads never become available - we have
    to restart the server.
    I realize that this is a pretty generic description of the problem :-) but I wonder
    if anyone else has encountered this and has an idea what might be causing it ?
    Right now I am guessing that something in our code causes a resource contention
    that eventually deadlocks all the threads. But that is just a guess.

    Ethan,
    "Ethan Allen" <[email protected]> wrote in message
    news:3e0220a1$[email protected]..
    Thanks, Dimitri and Slava !
    I will do this and learn a little emore ...FYI, there is a web site dedicated to weblogic documentation -
    http://e-docs.bea.com/
    Pick your server version, go to "Search", type "thread dump".
    Regards,
    Slava Imeshev
    >
    ethan
    "Slava Imeshev" <[email protected]> wrote:
    Hi Ethan,
    For windows press <Ctrl>+<Break> in the server shell window,
    for *nix send kill -3 {server PID}.
    Regards,
    Slava Imeshev
    "Ethan Allen" <[email protected]> wrote in message
    news:3e020fb4$[email protected]..
    Thanks for your reply, Dimitri.
    We have not looked at thread dumps. How may we do this ?
    Ethan
    "Dimitri I. Rakitine" <[email protected]> wrote:
    Did you try looking at thread dumps when this happens ?
    Ethan Allen <[email protected]> wrote:
    We've set up thread pools for several execute queues dedicated to
    high-load
    servlets
    in our application. Once in a while, we get into a condition in
    which
    none of
    these threads are available and then the threads never become
    available
    - we have
    to restart the server.
    I realize that this is a pretty generic description of the problem:-) but I wonder
    if anyone else has encountered this and has an idea what might be
    causing
    it ?
    Right now I am guessing that something in our code causes a
    resource
    contention
    that eventually deadlocks all the threads. But that is just a
    guess.
    >>>>
    Dimitri

  • The problem in the thread pool implemented by myself

    Hello, I need to a thread pool in J2ME CDC 1.0 + FP 1.0, so I implemented a simple one by myself that also meets my own requirement.
    Here is the main idea:
    The thread pool creates a fixed number of threads in advance. When a task comes, it is put in the waiting list. All threads tries to get the tasks from the waiting list. If no task exists, the threads wait until someone wakes them up.
    Here are the requirements from myself:
    1. when a task has finished its work in one execution, it is put in the waiting list for the next run.
    2. the task can control the delay between when the task owner tries to put it in the waiting list and when the task is actually put in the waiting list. I need this function because sometimes I don't want the tasks to run too often and want to save some CPU usage.
    In my program, I creates two thread pools. In one pool, every task don't use the delay, and the thread pool works very well. The other pool has the tasks that use the delay, and sometimes, as I can see from the printed information, there are many tasks in the waiting list but 0 or 1 thread executes tasks. It seems that the waiting threads cannot wake up when new tasks comes.
    I suspect the code in addTask(), but cannot find the reason why it fails. Could anyone please help me find out the bug in my code? I put the code of thread pool below
    Thank you in advance
    Zheng Da
    ThreadPool.java
    package j2me.concurrent;
    import java.util.LinkedList;
    import java.util.Timer;
    import java.util.TimerTask;
    import alvis.general.Util;
    public class ThreadPool {
         private int maxQueueSize;
         private boolean running = true;
         private Thread[] threads;
         private LinkedList tasks = new LinkedList();
         private Timer timer = new Timer(true);
         private AtomicInteger usingThreads = new AtomicInteger(0);
         private synchronized boolean isRunning() {
              return running;
         private synchronized void stopRunning() {
              running = false;
         private synchronized PoolTask getTask() {
              while (tasks.isEmpty() && isRunning()) {
                   try {
                        this.wait();
                   } catch (InterruptedException e) {
                        e.printStackTrace();
              if (tasks.isEmpty())
                   return null;
              // Util.log.info(Thread.currentThread().getName() +
              // " gets a task, left tasks: " + tasks.size());
              return (PoolTask) tasks.removeFirst();
         private synchronized void addTaskNoDelay(PoolTask task) {
              tasks.addLast(task);
              notifyAll();
         private synchronized void addTask(final PoolTask task) {
              long delay = task.delay();
              if (delay == 0) {
                   addTaskNoDelay(task);
              } else {
                   timer.schedule(new TimerTask() {
                        public void run() {
                             addTaskNoDelay(task);
                   }, delay);
         private synchronized int numTasks() {
              return tasks.size();
         private class PoolThread extends Thread {
              public void run() {
                   Util.poolThreads.inc();
                   while (isRunning()) {
                        PoolTask task = getTask();
                        if (task == null) {
                             Util.poolThreads.dec();
                             return;
                        usingThreads.inc();
                        long currentTime = System.currentTimeMillis();
                        task.run();
                        long elapsedTime = System.currentTimeMillis() - currentTime;
                        if (elapsedTime > 100)
                             System.err.println(task.toString() + " takes " + ((double) elapsedTime)/1000 + "s");
                        usingThreads.dec();
                        if (!task.finish()) {
                             addTask(task);
                   Util.poolThreads.dec();
         public ThreadPool(int size, int taskQueueSize) {
              maxQueueSize = taskQueueSize;
              threads = new Thread[size];
              for (int i = 0; i < threads.length; i++) {
                   threads[i] = new PoolThread();
                   threads.start();
         public synchronized boolean executor(PoolTask task) {
              if (!isRunning()) {
                   return false;
              Util.log.info("Thread Pool gets " + task + ", there are "
                        + numTasks() + " waiting tasks");
              if (numTasks() >= maxQueueSize) {
                   return false;
              addTask(task);
              return true;
         public synchronized void destroy() {
              stopRunning();
              timer.cancel();
              // TODO: I am not sure it can wake up all threads and destroy them.
              this.notifyAll();
         public synchronized void printSnapshot() {
              System.err.println("using threads: " + usingThreads + ", remaining tasks: " + tasks.size());
    PoolTask.javapackage j2me.concurrent;
    public interface PoolTask extends Runnable {
         * It shows if the task has already finished.
         * If it isn't, the task will be put in the thread pool for the next execution.
         * @return
         boolean finish();
         * It shows the delay in milliseconds that the task is put in the thread pool.
         * @return
         long delay();

    are receiving/sends tasks packets time consuming operation in your case or not? if it is not you do not need to use thread pools at all. you can create a queue like in your code through the linked list and dispatch this queue periodically with minimum monitor usage. try this.
    import java.util.LinkedList;
    public class PacketDispatcher extends Thread {
        LinkedList list = new LinkedList();
        public PacketDispatcher (String name) {
            super(name);
        public void putTask(Task task) {
            synchronized (list) {
                list
                        .add(task);
                list.notify();
        public void run() {
            while (true/* your condition */) {
                Task task = null;
                synchronized (list) {
                    while (list.isEmpty())
                        try {
                            list.wait();
                        } catch (InterruptedException e) {
                            e.printStackTrace();
                    task = (Task)list
                            .poll();
                if (task == null) {
                    try {
                        Thread
                                .sleep(1);
                    } catch (InterruptedException e) {
                        e.printStackTrace();
                    continue;
                task
                        .run();
                if (!task.isFinished()) {
                    putTask(task);
                Thread
                        .yield();
        public static void main(String[] args) {
            // just for test
            try {
                Thread.sleep (10000);
            } catch (InterruptedException e) {
                // TODO Auto-generated catch block
                e.printStackTrace();
            PacketDispatcher dispatcher = new PacketDispatcher("Packet Dispatcher");
            Task task = new Task();
            dispatcher.putTask(task);
            dispatcher.start();
            try {
                Thread.sleep (10000);
            } catch (InterruptedException e) {
                // TODO Auto-generated catch block
                e.printStackTrace();
            Task task2 = new Task();
            dispatcher.putTask(task2);
    class Task {
        long result = 0;
        public boolean isFinished () {
            if (getResult() >= 10000000) {
                return true;
            return false;
        public void run() {
            for (int i = 0; i < 1000; i++) {
                result += i;
        public long getResult () {
            return result;       
    }

  • JRun Thread Pool Issue

    I'm running CF 9.0.1 on Ubuntu on an "Medium" Amazon EC2 instance. CF has been crashing intermittently (several times per day). At such times, running top gets me this (or something similar):
    PID
    USER
    PR
    NI
    VIRT
    RES
    SHR
    S
    %CPU
    %MEM
    TIME+COMMAND                                                                                                   
    15855
    wwwrun
    20
    0
    1762m
    730m
    20m
    S
    99.3
    19.4
    13:22.96 coldfusion9
    So, it's obviously consuming most of the server resources. The following error has been showing up in my cfserver.log in the leadup to each crash:
    java.lang.RuntimeException: Request timed out waiting for an available thread to run. You may want to consider increasing the number of active threads in the thread pool.
    If I run /opt/coldfusion9/bin/coldfusion status, I get:
    Pg/Sec  DB/Sec  CP/Sec  Reqs  Reqs  Reqs  AvgQ   AvgReq AvgDB  Bytes  Bytes
    Now Hi  Now Hi  Now Hi  Q'ed  Run'g TO'ed Time   Time   Time   In/Sec Out/Sec
    0   0   0   0   -1  -1  150   25    0     0      -1352560      0      0
    In the administrator, under Server Settings > Request Tuning, the setting for Maximum number of simultaneous Template requests is 25. So this makes sense so far. I could just increase the thread pool to cover these sort of load spikes. I could make it 200. (Which I did just now as a test.)
    However, there's also this file /opt/coldfusion9/runtime/servers/coldfusion/SERVER-INF/jrun.xml. And some of the settings in there appear to conflict. For example, it reads:
    <service class="jrunx.scheduler.SchedulerService" name="SchedulerService">
      <attribute name="bindToJNDI">true</attribute>
      <attribute name="activeHandlerThreads">25</attribute>
      <attribute name="maxHandlerThreads">1000</attribute>
      <attribute name="minHandlerThreads">20</attribute>
      <attribute name="threadWaitTimeout">180</attribute>
      <attribute name="timeout">600</attribute>
    </service>
    Which a) has fewer active threads (what does this mean?), and b) has a max threads that exceed the simultaneous request limit set in the admin. So, I'm not sure. Are these independent configs that need to be made to match manually? Or is the jrun.xml file supposed to be written by the CF Admin when changes are made there? Hmm. But maybe this is different because presumably the CF Scheduler should only use a subset of all available threads, right...so we'd always have some threads for real live users. We also have this in there:
    <service class="jrun.servlet.http.WebService" name="WebService">
      <attribute name="port">8500</attribute>
      <attribute name="interface">*</attribute>
      <attribute name="deactivated">true</attribute>
      <attribute name="activeHandlerThreads">200</attribute>
      <attribute name="minHandlerThreads">1</attribute>
      <attribute name="maxHandlerThreads">1000</attribute>
      <attribute name="mapCheck">0</attribute>
      <attribute name="threadWaitTimeout">300</attribute>
      <attribute name="backlog">500</attribute>
      <attribute name="timeout">300</attribute>
    </service>
    This appears to have changed when I changed the CF Admin setting...maybe...but it's the activeHandlerThreads that matches my new maximum simulataneous requests setting...rather than the maxHandlerThreads, which again exceeds it. Finally, we have this:
    <service class="jrun.servlet.jrpp.JRunProxyService" name="ProxyService">
      <attribute name="activeHandlerThreads">200</attribute>
      <attribute name="minHandlerThreads">1</attribute>
      <attribute name="maxHandlerThreads">1000</attribute>
      <attribute name="mapCheck">0</attribute>
      <attribute name="threadWaitTimeout">300</attribute>
      <attribute name="backlog">500</attribute>
      <attribute name="deactivated">false</attribute>
      <attribute name="interface">*</attribute>
      <attribute name="port">51800</attribute>
      <attribute name="timeout">300</attribute>
      <attribute name="cacheRealPath">true</attribute>
    </service>
    So, I'm not certain which (if any) of these I should change and what exactly the relationship is between maximum requests and maximum threads. Also, since several of these list the maxHandlerThreads as 1000, I'm wondering if I should just set the maximum simultaneous requests to 1000. There must be some upper limit that depends on available server resources...but I'm not sure what it is and I don't really want to play around with it since it's a production environment.
    I'm not sure if it pertains to this issue at all, but when I run a ps aux | grep coldfusion I get the following:
    wwwrun   15853  0.0  0.0   8704   760 pts/1
    S
    20:22   0:00 /opt/coldfusion9/runtime/bin/coldfusion9 -jar jrun.jar -autorestart -start coldfusion
    wwwrun   15855  5.4 18.2 1678552 701932 pts/1  
    Sl
    20:22   1:38 /opt/coldfusion9/runtime/bin/coldfusion9 -jar jrun.jar -start coldfusion
    There are always these two and never more than these two processes. So there does not appear to be a one-to-one relationship between processes and threads. I recall from an MX 6.1 install I maintained for many years that additional CF processes were visible in the process list. It seemed to me at the time like I had a process for each thread...so either I was wrong or something is quite different in version 9 since it's reporting 25 running requests and only showing these two processes. If a single process can have multiple threads in the background, then I'm given to wonder why I have two processes instead of one...just curious.
    So, anyway, I've been experimenting while composing this post. As noted above I adjusted the maximum simulataneous requests up to 200. I was hoping this would solve my problem, but CF just crashed again (rather it slogged down and requests started timing out...so effectively "crashed"). This time, top looked similar (still consuming more than 99% of the CPU), but CF status looked different:
    Pg/Sec  DB/Sec  CP/Sec  Reqs  Reqs  Reqs  AvgQ   AvgReq AvgDB  Bytes  Bytes
    Now Hi  Now Hi  Now Hi  Q'ed  Run'g TO'ed Time   Time   Time   In/Sec Out/Sec
    0   0   0   0   -1  -1  0     150   0     0      0      0      0      0
    Obviously, since I'd increased the maximum simultaneous requests, it was allowing more requests to run simultaneously...but it was still maxing out the server resources.
    Further experiments (after restarting CF) showed me that the server became unusably slogged after about 30-35 "Reqs Run'g", with all additional requests headed for an inevitible timeout:
    Pg/Sec  DB/Sec  CP/Sec  Reqs  Reqs  Reqs  AvgQ   AvgReq AvgDB  Bytes  Bytes
    Now Hi  Now Hi  Now Hi  Q'ed  Run'g TO'ed Time   Time   Time   In/Sec Out/Sec
    0   0   0   0   -1  -1  0     33    0     0      -492   0      0      0
    So, it's clear that increasing the maximum simultaneous requests has not helped. I guess what it comes down to is this: What is it having such a hard time with? Where are these spikes coming from? Bursts of traffic? On what pages? What requests are running at any given time? I guess I simply need more information to continue troubleshooting. If there are long-running requests, or other issues, I'm not seeing it in the logs (although I do have that option checked in the admin). I need to know which requests exactly are those responsible for these spikes. Any help would be much appreciated. Thanks.
    ~Day

    I really appreciate your help. However, I haven't been able to find the JRun Thread settings you describe above.
    Under Request Tuning, I see:
    Server Settings > Request Tuning
    Request Limits
    Maximum number of simultaneous Template requests
      Restricts the number of simultaneously processed requests. Use this setting to increase overall system performance for heavy load applications. Requests beyond the specified limit are queued. On Standard Edition, you must restart ColdFusion to enable this setting. 
    Maximum number of simultaneous Flash Remoting requests
      The number of Flash Remoting requests that can be processed concurrently.
    Maximum number of simultaneous Web Service requests
      The number of Web Service requests that can be processed concurrently.
    Maximum number of simultaneous CFC function requests
      The number of ColdFusion Component methods that can be processed concurrently via HTTP. This does not affect invocation of CFC methods from within CFML, only methods requested via an HTTP request.
    Tag Limit Settings
    Maximum number of simultaneous Report threads
      The maximum number of ColdFusion reports that can be processed concurrently.
    Maximum number of threads available for CFTHREAD
      The maximum number of threads created by CFTHREAD that will be run concurrently. Threads created by CFTHREAD in excess of this are queued.  On Standard Edition, the maximum limit is 10. 
    And under Java and JVM, I see:
    Server Settings > Java and JVM
        Java and JVM settings control the way ColdFusion starts the Java Virtual Machine when it starts.  You can control settings like what classpaths are used and how memory is allocated as well as add custom command line arguments.  Changing these settings requires restarting ColdFusion.  If you enter an incorrect setting, ColdFusion may not restart properly. 
       Backups of the jvm.config file are created when you hit the submit button. You can use this backup to restore from a critical change. 
       Java Virtual Machine Path
      Specifies the location of the Java Virtual Machine.
       Minimum JVM Heap Size (MB)         Maximum JVM Heap Size  (MB)       
       The Memory Size settings determine the amount of memory that the JVM can use for programs and data. 
       ColdFusion Class Path
      Specifies any additional class paths for the JVM, with multiple directories separated by  commas.
       JVM Arguments
      -server -Dsun.io.useCanonCaches=false -XX:MaxPermSize=192m -XX:+UseParallelGC -Xbatch -Dcoldfusion.rootDir={application.home}/../ -Dcoldfusion.libPath={application.home}/../lib
      Specifies any specific JVM initialization options, separated by spaces.
    I did go take a look at FusionReactor and found it's not free (which would be fine, of course, if it would actually help). It looks like there's a fully functional demo, which is cool...but I've haven't been able to get it to install yet, so we'll see.
    Thanks again!
    ~Day
    (By the way, I've cross-posted this inquiry on StackOverflow. So if you're able to help me arrive at a solution you might want to answer there as well.)

  • Thread pool rejecting threads when I don't think it should, ideas?

    Hi,
    I have a server application in which I only want a specific number of simultaneous requests. If the server gets more then this number it is suppose to close the connection (sends an HTTP 503 error to the client). To do this I used a fix thread pool. When I start the server and submit the max number of requests I get the expected behavior. However if I resubmit the request (within a small period of time, e.g. 1-15 seconds after the first one) I get very odd behavior in that some of the requests are rejected. For example if I set the max to 100 the first set of requests will work fine (100 requests, 100 responses). I then submit again and a small number will be rejected (I've seen it range from 1 to 15 rejected)....
    I made a small app which kind of duplicates this behavior (see below). Basically when I see is that the first time submitting requests works fine but the second time I get a rejected one. As best as I can tell none should be rejected....
    Here is the code, I welcome your thoughts or if you see something I am doing wrong here...
    <pre>
    import java.util.concurrent.*;
    import java.util.concurrent.atomic.AtomicInteger;
    public class ThreadPoolTest {
         static AtomicInteger count = new AtomicInteger();
         public static class threaded implements Runnable {
              @Override
              public void run() {
                   System.out.println("In thread: " + Thread.currentThread().getId());
                   try {
                        Thread.sleep(500);
                   } catch (InterruptedException e) {
                        System.out.println("Thread: " + Thread.currentThread().getId()
                                  + " interuptted");
                   System.out.println("Exiting run: " + Thread.currentThread().getId());
         private static int maxThreads = 3;
         private ThreadPoolExecutor pool;
         public ThreadPoolTest() {
              super();
              pool = new java.util.concurrent.ThreadPoolExecutor(
                        1, maxThreads - 1, 60L, TimeUnit.SECONDS,
                        new ArrayBlockingQueue<Runnable>(1));
         public static void main(String[] args) throws InterruptedException {
              ThreadPoolTest object = new ThreadPoolTest();
              object.doThreads();
              Thread.sleep(3000);
              object.doThreads();
              object.pool.shutdown();
              try {
                   object.pool.awaitTermination(60, TimeUnit.SECONDS);
              } catch (InterruptedException e) {
                   // TODO Auto-generated catch block
                   e.printStackTrace();
         private void doThreads() {
              int submitted = 0, rejected = 0;
              int counter = count.getAndIncrement();
              for (int x = 0; x < maxThreads ; x++) {
                   try {
                        System.out.println("Run #: " + counter + " submitting " + x);
                        pool.execute(new threaded());
                        submitted++;
                   catch (RejectedExecutionException re) {
                        System.err.println("\tRun #: " + counter + ", submission " + x
                                  + " was rejected");
                        System.err.println("\tQueue active: " + pool.getActiveCount());
                        System.err.println("\tQueue size: " + pool.getPoolSize());
                        rejected++;
              System.out.println("\n\n\tRun #: " + counter);
              System.out.println("\tSubmitted: " + (submitted + rejected));
              System.out.println("\tAccepted: " + submitted);
              System.out.println("\tRejected: " + rejected + "\n\n");
    </pre>

    First thank you for taking the time to reply, I do appreciate it.
    jtahlborn - The code provided here is a contrived example trying to emulate the bigger app as best as I could. The actual program doesn't have any sleeps, the sleep in the secondary thread is to simulate the program doing some work & replying to a request. The sleep in the primary thread is to simulate a small delay between 'requests' to the pool. I can make this 1 second and up to (at least) 5 seconds with the same results. Additionally I can take out the sleep in the secondary thread and still see the a rejection.
    EJP - Yes I am aware of the TCP/IP queue, however; I don't see that as relevant to my question. The idea is not to prevent the connection but to respond to the client saying we can't process the request (send an "HTTP 503" error). So basically if we have, say, 100 threads running then the 101st, connection will get a 503 error and the connection will be closed.
    Also my test platform - Windows 7 64bit running Java 1.6.0_24-b07 (32bit) on an Intel core i7.
    It occurred to me that I did not show the output of the test program. As the output shows below, the first set of requests are all processed properly. The second set of requests is not. The pool should have 2 threads and 1 slot in the queue, so by the time the second "request" is made at least 2 of the requests from the first call should be done processing, so I could possibly understand run 1, submit #2 failing but not submit 1.
    <pre>
    Run #: 0 submitting 0
    Run #: 0 submitting 1
    Run #: 0 submitting 2
    In thread: 8
    In thread: 9
    Exiting run: 8
    Exiting run: 9
         Run #: 0
         Submitted: 3
         Accepted: 3
         Rejected: 0
    In thread: 8
    Exiting run: 8
    Run #: 1 submitting 0
    In thread: 9
    Run #: 1 submitting 1
         Run #: 1, submission 1 was rejected
         Queue active: 1
         Queue size: 2
    Run #: 1 submitting 2
         Run #: 1
         Submitted: 3
         Accepted: 2
         Rejected: 1
    In thread: 8
    Exiting run: 9
    Exiting run: 8
    </pre>

  • Thread pool in servlet container

    Hello all,
    I'm working on this webapp that has some bad response times and I've identified an area were we could shave off a considerable amount of time. The app is invoking a component that causes data to be catched for subsequently targeted apps in the environemnt. Our app does not need to wait for a response so I'd like to make this an asyncronous call. So, how best to implement this?...I considered JMS, but started working on a solution using the Java 1.4 backport of JSR 166 (java.util.concurrent).
    I've been testing the use of a ThreadPoolExecutor, using an ArrayBlockingQueue. The work that each Runnable will perform involves a lot of waiting (the component we call invokes a web service, among a couple other distributed calls). So I figure the pool will be much larger than the queue. Our container has 35 execute threads, so I've been testing with a thread pool size of 25, and a queue of 10.
    Any thoughts on this approach? I understand that some of this work could be simplified by JMS, but if I don't need to be tied to the container, I'd prefer not to. The code if much easier to unit test, and plays nicely with our continious build integration (which runs our junit test for us and notifies on errors).
    Any thoughts are greatly appreciated...Thanks!!

    Well, if it works, that's by far the best way to go - but note that creating threads in a servlet container means those threads are outside of the container's control. Many containers will refuse to give the new threads access to the JNDI context, even, and some may prevent you from creating threads at all.

  • BEA-002900 Initializing self-tuning thread pool   HANGS

    Hi All,
    Trying to start a WLS 10.3.5 instance using jrockit and it is hanging on:
    Apr 6, 2013 2:08:39 AM CDT> <Info> <WorkManager> <BEA-002900> <Initializing self-tuning thread pool>
    end of trace
    I took a thread dump and see this:
    "[ACTIVE] ExecuteThread: '0' for queue: 'weblogic.kernel.Default (self-tuning)'" id=15 idx=0x3c tid=3810 prio=5 alive, waiting, native_blocked, daemon
    -- Waiting for notification on: weblogic/work/ExecuteThread@0xa0c21480[fat lock]
    at jrockit/vm/Threads.waitForNotifySignal(JLjava/lang/Object;)Z(Native Method)
    at java/lang/Object.wait(J)V(Native Method)
    at java/lang/Object.wait(Object.java:485)
    at weblogic/work/ExecuteThread.waitForRequest(ExecuteThread.java:162)
    ^-- Lock released while waiting: weblogic/work/ExecuteThread@0xa0c21480[fat lock]
    at weblogic/work/ExecuteThread.run(ExecuteThread.java:183)
    at jrockit/vm/RNI.c2java(JJJJJ)V(Native Method)
    -- end of trace
    "JFR request timer" id=16 idx=0x40 tid=3811 prio=5 alive, waiting, native_blocked, daemon
    -- Waiting for notification on: java/util/TaskQueue@0xa0c20b28[fat lock]
    at jrockit/vm/Threads.waitForNotifySignal(JLjava/lang/Object;)Z(Native Method)
    at java/lang/Object.wait(J)V(Native Method)
    at java/lang/Object.wait(Object.java:485)
    at java/util/TimerThread.mainLoop(Timer.java:483)
    ^-- Lock released while waiting: java/util/TaskQueue@0xa0c20b28[fat lock]
    at java/util/TimerThread.run(Timer.java:462)
    at jrockit/vm/RNI.c2java(JJJJJ)V(Native Method)
    -- end of trace
    ===== END OF THREAD DUMP ===============
    Done:
    1). Cleared TMP and CACHE directories and still does not solve the issue.
    Any ideas are appreciated.
    thanks

    Hi,
    we had same hang issue. Unfortunately we run behind VM.
    It was an issue with securerandom generation.
    We solved the issue as described here http://stackoverflow.com/a/2564406/2098832
    Also deleted the <server>/tmp directory before.
    Hope this helps.
    Casey

  • Pattern for Thread Pool?

    Hi
    i want to build a kind of download manager. The application should be able to handle some concurrent threads, each representing a download in progress.
    I thought i might be more efficient to reuse a download thread after the download has ended as to create a new thread each time (like the connection object for db queries). Is this right? If yes, i thought to build a thread pool that serves a limited number of threaded download objects as requested (am I on the right way?).
    Now, I have to basic problems: (a) is it right, that, if the run() method of a thread has ended, the whole thread gets destroved? if yes, how should i prevent the thread from being destroyed, so i can reuse it later on? Second (b) how would that pool mechnism look like, means, there must be some kind of vector where i put in and take out the threads.
    As you see, these are basic "pool" technique questions. So, I thought, maybe there is a design pattern that would give me the basic mechanism, Does anyone know such a pattern?
    Thanks for your help
    josh

    I thought i might be more efficient to reuse a
    download thread after the download has ended as to
    create a new thread each time (like the connection
    object for db queries). Is this right? If yes, iIt may be right, if creating new threads is wasting enough CPU cycles to justify the complication of a thread pool. Maybe for a high-load server it would be more efficient. You'll have to figure that out for your own specific application.
    Another good use for thread pools is to avoid putting time-consuming operations in ActionListeners, etc. Instead you can have them pass the task off to a thread pool, keeping the GUI responsive.
    Now, I have to basic problems: (a) is it right, that,
    if the run() method of a thread has ended, the whole
    thread gets destroved? if yes, how should i prevent
    the thread from being destroyed, so i can reuse it
    later on? Second (b) how would that pool mechnism look
    like, means, there must be some kind of vector where i
    put in and take out the threads. (a) You are right. Therefore, the worker threads should not exit their run() methods until interrupted. (b) Worker threads could check a job queue (containing Runnables, perhaps) and if there are none, they should wait() on some object. When another thread adds a new job to the queue, it should call notify() on the same object, thus waking up one of the worker threads to perform the task.
    I wrote a thread pool once, just as an exercise. You will run into a number of problems and design issues (such as, what should the worker threads do when interrupted, exit immediately or clear the job queue and then exit?) If you have any more questions, ask in this thead.
    Krum

  • Using AsyncEventHandlers as a RTJ buildin thread pool

    Hi David
    1. I would like to use AsyncEventHandler mechanism as a thread pool. Would there be a way in future version to access the AsyncEventHandler's RT Thread pool API ?
    2. I am using the BoundAsyncEventHandler for long duration task (since the BoundAsyncEventHandler is bound to a specific Thread) - Would there be a way in future version to bound a specific RT Thread to this handler ? - for example a RT Thread that was created by my own Thread pool ?
    Thanks

    Gabi wrote:
    1.We need our code to access the AEH's "thread pool" and check the pool's availability; increase/decrease the pool size dynamically; check pool size for enough free threads to run any given number of tasks and so on...There are no API's for this. How a VM supports AEH execution is an implementation detail, and while a "pool" is the logical form of implementation the details can vary significantly so there's no real way to define an API to control it without defining what form it must take. For example in Java RTS the pool threads are initially at the highest system priority and then drop down to the priority of the AEH they execute. In a different design you might have a pool of threads per priority level (or set of priority levels) so even the notion of increasing/decreasing the pool size is not necessarily straight-forward. In Java RTS the pool will grow as needed to service outstanding AEH activations. You can control the initial number of threads - and there are two pools: one of heap-using and one for non-heap AEH.
    2. I was thinking about adding the BAEH class with the next method:
    void setBoundThread(RTThread t) throws IllegalArgumentExceptionand also in the Ctor add the RTThread as a parameter.
    Inside this method, the thread should be check if started and is so should throw an IllegalArgumentException.Sure, but why do you need to do this? What is different about the RTT that you pass in? The thread executing an AEH acquires the characteristics of the AEH.
    An API like this raises some questions such as: when would the thread be started? It also has a problem in that the run() method of the thread has to know how to execute an AEH, which means we'd (the RTSJ expert group) probably have to define a class BoundAEHThread that has a final run() method and you'd then subclass it.
    3. Additional question, what do you think about using lock (CountdownLatch) during the AEH's executions ?
    I've seen somewhere that AEH should only be used for short live tasks - is it true ? (in the JavaDoc it says there is no problem doing so but I want to be sure)If an AEH blocks for any length of time and additional AEH are activated then the pool management overhead may increase (unless you already sized it appropriately). But otherwise there's no restriction on what the code in an AEH can do. But note that none of the java.util.concurrent synchronization tools support priority-inversion avoidance, so you need to be careful if using them (ie only use them across threads of the same priority and don't expect FIFO access).
    David Holmes

  • Thread Pool design

    I have one service that processes messages, now I want it to run it in multi threads so it can execute faster. Now my question is how can I make thread pool- what is best design. Since I dont want to create n number of thereads to process n number of messages, I should create thread pool with predefined number of threads.
    So my main program will do something like this
    1)Check thread pool - if available
    2)If available create tak and execute
    3)If not wait (how to wait???)
    4)Once thread has done it should be available for next processing if requred.
    Thanks in advance.

    I am not using put, I am not directly using array queue, what I understand is like its for its internal use. Here is what I am trying with,
    Thread pool  class
    import java.util.concurrent.BlockingQueue;
    import java.util.concurrent.ThreadPoolExecutor;
    import java.util.concurrent.TimeUnit;
    public class MyThreadPool extends ThreadPoolExecutor {
         public MyThreadPool(int corePoolSize, int maximumPoolSize, long keepAliveTime,
                   TimeUnit unit, BlockingQueue<Runnable> queue) {
              super(corePoolSize, maximumPoolSize, keepAliveTime, unit, queue);
    Thread- Runnable object
    public class MyThread implements Runnable{
         public void run() {
              System.out.println("This is MyThread running...");
              try {
                   Thread.currentThread().sleep(1*5*1000);
                   System.out.println("Complted...");
              } catch (InterruptedException e) {
                   e.printStackTrace();
    Main program
    public class MyClient {
         public static void main(String[] args) {
              ArrayBlockingQueue queue = new ArrayBlockingQueue(5, false);
              MyThreadPool myThreadPool = new MyThreadPool(5, 5, 1, TimeUnit.SECONDS, queue);
              for (int i = 0; i < 6; i++) {
                   MyThread t = new MyThread();
                   if(myThreadPool.getTaskCount() != 1)
                        myThreadPool.submit(t);
    }now see my queue size is 5 and I am submitting 6 jobs to execute. When I run main class, it runs all jobs and program never terminates.
    Output:
    This is MyThread running...
    This is MyThread running...
    This is MyThread running...
    This is MyThread running...
    This is MyThread running...
    Complted...
    This is MyThread running...
    Complted...
    Complted...
    Complted...
    Complted...
    Complted...
    Edited by: Miral on Apr 8, 2009 2:16 PM
    Edited by: Miral on Apr 8, 2009 2:17 PM
    Edited by: Miral on Apr 8, 2009 2:17 PM

  • Thread pool library

    Hello all,
    Does anybody know an open-source library that provides a thread pool with the following behavior?
    When a task is submitted...
    if (there are idle threads in the pool) {
        use an idle thread to execute the task.
    } else {
        if (currentThreadCount < maximumPoolSize) {
            create new thread to execute the task.
        } else {
            put the task in the queue.
            (tasks in the queue will be processed when threads are available).
    }If a thread remains idle for X time, it dies.
    Thank you

    I ran your code and it ran it just fine, I prefixed your println to print out the currentTimeMillis to show it ran right after each other.
    System.out.println(System.currentTimeMillis() +  "{code}
    Here is the result:
    1244482518471 Starting main.
    1244482518483 Running a task
    Here is code fragments from ThreadPoolExecutor I generated my sudo code from.
    {code}
         * Executes the given task sometime in the future.  The task
         * may execute in a new thread or in an existing pooled thread.
         * If the task cannot be submitted for execution, either because this
         * executor has been shutdown or because its capacity has been reached,
         * the task is handled by the current <tt>RejectedExecutionHandler</tt>.
         * @param command the task to execute
         * @throws RejectedExecutionException at discretion of
         * <tt>RejectedExecutionHandler</tt>, if task cannot be accepted
         * for execution
         * @throws NullPointerException if command is null
        public void execute(Runnable command) {
            if (command == null)
                throw new NullPointerException();
            if (poolSize >= corePoolSize || !addIfUnderCorePoolSize(command)) {
                if (runState == RUNNING && workQueue.offer(command)) {
                    if (runState != RUNNING || poolSize == 0)
                        ensureQueuedTaskHandled(command);
                else if (!addIfUnderMaximumPoolSize(command))
                    reject(command); // is shutdown or saturated
         * Creates and starts a new thread running firstTask as its first
         * task, only if fewer than corePoolSize threads are running
         * and the pool is not shut down.
         * @param firstTask the task the new thread should run first (or
         * null if none)
         * @return true if successful
        private boolean addIfUnderCorePoolSize(Runnable firstTask) {
            Thread t = null;
            final ReentrantLock mainLock = this.mainLock;
            mainLock.lock();
            try {
                if (poolSize < corePoolSize && runState == RUNNING)
                    t = addThread(firstTask);
            } finally {
                mainLock.unlock();
            if (t == null)
                return false;
            t.start();
            return true;
         * Rechecks state after queuing a task. Called from execute when
         * pool state has been observed to change after queuing a task. If
         * the task was queued concurrently with a call to shutdownNow,
         * and is still present in the queue, this task must be removed
         * and rejected to preserve shutdownNow guarantees.  Otherwise,
         * this method ensures (unless addThread fails) that there is at
         * least one live thread to handle this task
         * @param command the task
        private void ensureQueuedTaskHandled(Runnable command) {
            final ReentrantLock mainLock = this.mainLock;
            mainLock.lock();
            boolean reject = false;
            Thread t = null;
            try {
                int state = runState;
                if (state != RUNNING && workQueue.remove(command))
                    reject = true;
                else if (state < STOP &&
                         poolSize < Math.max(corePoolSize, 1) &&
                         !workQueue.isEmpty())
                    t = addThread(null);
            } finally {
                mainLock.unlock();
            if (reject)
                reject(command);
            else if (t != null)
                t.start();
    {code}                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                   

  • Thread Pool in JRT

    Hi All,
    1) the first question is what is the recommended way to allocate thread poll in rt system??
    2) what is the best way to do:
    -if my mission take a long time can i just suspend the thread and than resume it again (is it possible at all??)
    or the other option is to return it to the pool and get it again and again.
    im asking the second question from the view of performance and low latency .
    i assumed that each time i return the thread to the pool and than active it again it will "cost" cpu time.
    hope my question is clear enough.
    TIA
    Gabi

    Hi Gabi,
    I'm not completely clear on your questions. You can create a thread pool in a RT system the same basic way as in non-RT but you need to deal with priorities correctly. One way to do this would be to have the pool threads run at maximum priority normally and then drop to the actual priority of a submitted work task. Another model is to split the pool into groups based on priority, so effectively there is a work queue per priority-level and a group of threads to service each pool. This second model is used in the Real-time CORBA "lanes" approach. Designing an effective thread pool is a non-trivial task (take a look at the java.util.concurrent Thread PoolExecutor) and dealing with RT priorities and RT latency issues makes it even more complex.
    Alternatively rather than use an explicit thread pool consider whether you can convert the design to one using AsyncEvents and AsyncEventHandlers.
    Question 2 I don't really understand. Pool threads typically block on a queue waiting for work tasks to appear. But you can also have a non-terminating task that effectively picks up its own work from elsewhere - eg a task that reads from a socket to get the next "job" to process. Any interaction between threads is going to cost CPU time, whether a pool is involved or not, but yes there will be overhead associated with a pool, just as there is starting and terminating a thread, or performing any kind of thread coordination/synchronization.
    Regards,
    David Holmes

Maybe you are looking for