Maximum number of running JRun threads - where to set?

Hi,
I have been looking to increase the maximum number of JRun threads on CF8 Standard on Linux. However, changing jrun.xml (<attribute name="activeHandlerThreads">100</attribute> in the JRunProxyService section) did nothing after restarting CF and Apache and I have not been able to find it anywhere in the Administrator. Anybody have any ideas or have I missed something really obvious?
CF administrator does not list the value anywhere apart from the settings summary.
Thanks
Meint

Ok, I changed the WebService setting and it now shows the new value in CF Administrator. However, it does have me wondering if this is possibly a bug in CF Administrator? Does it always show the JRun threads against the internal web server, even if you are using an external web server like Apache? Reason for asking is that the relevant sections against the JrunProxyService section clearly state that this is for an external web server and the WebService section states it is for the internal web swerver? Bit confused now but have got it working as expected. Is there another way of finding out the JRun thread value other than the CF Administrator?
Regards
Meint

Similar Messages

  • [Project Server 2010] Maximum Number of Job processor Threads in the queue settings

    Hello,
    I have a farm with SharePoint 2010 and Project Server 2010 installed. The farm contains:
    2 web front end servers
    3 application servers
    Each servers has 4 processors
    The SQL databases are installed on our database servers.
    The Microsoft Project Server Queue Service 2010 is started on the 2 web front end servers and on 1 applicative server.
    We have two instances of PWA are installed on this farm.
    I have calculated that the number of availabe processors we could have on this farm is : 4 processors X 3 application servers (the ones where the project queue is started) = 12. Is that correct? I'm not sure of the definition of the applicaton
    server that is used in
    this article )
    If I set the Maximum Number of Job Processor Threads (in the queue setting) to 2 per queue and per instance. We could have 2 Job processor X 3 application servers X 2 pwa instance = 12 threads to operate at the same time, is it correct?
    If yes, do you think this is a too high number of threads?
    Thanks for your help
    Aline

    Hi Aline,
    These settings are for fine tuning the servers, and are only one of many performance parameters.  If you notice the response from the server is slow, regarding Queues, then I would think about amending these upwards, but also with a careful eye on processor
    utilisation.  If you up the thread count and the system isn't any more performant, then I would look elsewhere for perf improvements.  Before you do anything of course, baseline the performance of the system.
    Ben Howard [MVP] | web |
    blog |
    book | P2O

  • 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.)

  • Maximum  Number of Nodes 10000 reached

    Hi Im using a loop condition for deadline rendering with system time then the worlkflow showing error with the message
    "Maximum  Number of Nodes 10000 reached" where im going wrong
    im checking my dealine requirement for every 3 minutes by using loop condition  original requirement is to check for every 3 days
    im confused over here where im going wrong
    Thanks

    Hi Prasad,
    As suggested by our friends, there is no termination condition in the loop , and it has become an infinite loop.
    To elaborate this error description, find extarcts from help :
    Maximum number of nodes that can be processed at runtime before the workflow runtime system assumes an endless loop and cancels the current workflow.
    The presetting for this value is 10000.
    Regards,
    Akshay

  • Maximum number of mail processes exceeded

    I've got problems with my mailserver. I already had them, but after a restart the problems didn't occur. From today after sys updates I have them back.
    Some clients mostly iPhones can't connect to my mailserver.
    In the system log I have the following error message:
    Jul 26 15:07:49 miniserver dovecot[60]: Maximum number of mail processes exceeded (see maxmailprocesses setting)
    I don't know where these settings are in a config file.
    I also have problems with webmail, I I want to login I get an error message: Unknown error: Internal login failure. Refer to server log for more information.
    Thanks,
    Patrick

    I found the config file and edited in: /etc/dovecot/dovecot.conf
    Settings were: mailmacprocesses: 3
    Changed it to 300 and voila.

  • Maximum number of open files..

    I'm looking for some help...probably a consultant to give us a call.
    I need to know the following:
    For 2.6 and 7, number of open files per process default and maximum setting.
    Procedure to change the default setting to the maximum
    Amont of RAM required to handle the max setting.
    Risks inherent in setting this parameter to the max.
    Any info on test environments where max setting has been utilized (e.g. datase TPC benchmarks, etc..)
    Feel free to call 408.861.1103 - happy to pay for the advice.

    Hi!
    The maximum number of file descriptors per process is set by two parameters:
    rlim_fd_cur (soft limit, defaults to 64)
    rlim_fd_max (hard limit, defaults to 1024)
    Processes may raise their soft limit up to the hard limit using setrlimit(2).
    Setting rlim_fd_cur high is not a problem as the file desciptors are allocated in chunks of 24 as required, and so not all in one go. They don't actually require that much memory either.
    As administrator you may set the limits by adding an entry to /etc/system, eg:
    set rlim_fd_max=600
    and rebooting.
    Note however on 32 bit solaris, the significant limitation is that the stdio library FILE structure limits your process to 256 fds. This is increased to 65536 for 64bit programs on solaris 7.
    Select(3c) can use up to 65536 fds (#define FD_SETSIZE 65536 in your code for 32bit solaris 7).
    Hope that helps.
    Ralph
    SUN DTS

  • Maximum number of threads

    I have an application for which I am interested in obtaining as many simultaneous
    threads as possble (e.g. 10's and possibly 100's of thousands of threads).
    More specifically I have developed a simulation language formalism in which the
    dynamics of each "entity" moving through a network of queues is coordinated by
    a separate thread of execution.
    This is not a traditional application where all or even some small number are
    intended to run concurrently. A single executive thread is responsible for alternately
    activating and deactivating individual threads to reflect the time ordered sequencing
    of events corresponding to each entity's movement through the system of queues.
    As a result, only a single thread is executing at one time.
    Using a separate thread for each entity off-loads the task of managing each's
    execution context to the JVM. The resource contention issues that arise in a
    standard multi-threaded application don't apply here.
    For "large" systems though (ones populated by many entities simultaneously) I
    need many threads.
    I'm using JRockit's thin thread model on a Windows XP machine and am "only" able
    to get approximately 25000 threads at which point the JVM hangs with no diagnostic.
    I say "only" because at that point there seems to be plenty of heap space left
    as well as Page File space left in the XP's Virtual Memory system.
    I'm using the following JVM command line:
    java -Xthinthreads -Xss32K -Xms256M -Xmx256M -Xallocationtype:global
    Surprisingly, by altering the heap size upward from 256MB to 512MB acutally causes
    the VM to hang with fewer threads (only 20000 or so)
    Using allicationtype:global and altering the stack size of the threads seems to
    have little effect on the maximum number attainable.
    It seems the maximum number of threads attaible should be a function of the size
    of the heap space, and the amount of physical and virtual memory limits on the
    system.
    My empirical evidence, however, seems to indicate there is some internal VM limit.
    Can someone explain for me the implementation of the thin thread model and its
    limitations w.r.t. the number of threads it can support?
    Thanks in advance for you help.

    You might try to use the new java.util.concurrent.* api available in j2se
    1.5.0 as
    a base for your implementation instead.
    /Robert
    "Staffan Larsen" <[email protected]> wrote in message
    news:40f63c6b$1@mktnews1...
    The reason for the "artifical" limitation of 32767 is that each thread
    needs to have it's own id. The way the object synchonization algorithm
    works, there has to be space for this id in the header of each object.
    The header has a very limited amount of space (currently 2 words) and
    thus there is not space for a larger thread id than 32767.
    You may be interested (but sad) to know that the thinthreads model has
    been removed from later versions of JRockit. The reason was the overhead
    of maintaining and supporting multiple threading systems was just too
    much work for a small return. Although, for very specialized systems
    (like yours) it would give a higher return.
    About your calculation. You said in you first post that you set -Xss32k
    which means that each thread will take at least 32k memory, more likey
    40k with other overhead. That means about 25 threads per MB or 25000 per
    GB, given that everything scales linearly.
    Regards,
    /Staffan
    Kevin Healy wrote:
    Staffan,
    Thanks for your response. Certainly in a traditional multi-threaded
    applications
    where there exist many runnable threads competing for resources, thepoint of
    diminishing returns is usually on the order of 10's of threads; but, asI mentioned,
    this is not a traditional application. In this case, the threadingframework
    is used as a natural and convenient way to manage the execution contextof the
    (many) entities in the system. Since I'm not interested in trueconcurrency or
    exploiting parallelism, I view threads as just data and it strikes methat I should
    be able to get as many as I have room for. In fact the green threadsmodel of
    the pre JDK 1.4 JVM's was well-suited to this kind of application but itseems
    the JVM implementors have not considered this in removing support forgreen threads
    in their newest releases. The thin threads model of JRockit is the nextbest
    thing but the 32767 limit seems entirely artificial.
    Do you know of any way to bump up that limitation or who I might contactat BEA
    about the matter?
    I'm aware that stack space and other context specific data must beallocated for
    each thread so let's say for the sake of argument that each thread takes10KB
    of data. That means I get 100 threads per 1MB and it would take 1GB toget my
    100,000 threads. That is not an unusually large amount of data ontoday's desktop
    computer. Furthermore, with the advent of 64bit computing on thedesktop, we'll
    see machines supporting much more than 4GB.
    Staffan Larsen <[email protected]> wrote:
    First: which version of JRockit is this with?
    With thinthreads the limit is 32767 threads. But you may run into other
    limits before that. When you increase the heapsize you "steal" memory
    from the system (which would otherwise be used for stacks and other data
    structures) and that is why you can run fewer threads with a larger
    heap.
    >>>
    I don't think it is realistic to run 100's of thousands of threads in
    one single system.
    Regards,
    /Staffan
    Kevin Healy wrote:
    I have an application for which I am interested in obtaining as manysimultaneous
    threads as possble (e.g. 10's and possibly 100's of thousands of
    threads).
    >>>>
    More specifically I have developed a simulation language formalismin which the
    dynamics of each "entity" moving through a network of queues is
    coordinated
    >>>
    by
    a separate thread of execution.
    This is not a traditional application where all or even some smallnumber are
    intended to run concurrently. A single executive thread is responsiblefor alternately
    activating and deactivating individual threads to reflect the timeordered sequencing
    of events corresponding to each entity's movement through the systemof queues.
    As a result, only a single thread is executing at one time.
    Using a separate thread for each entity off-loads the task of managingeach's
    execution context to the JVM. The resource contention issues thatarise in a
    standard multi-threaded application don't apply here.
    For "large" systems though (ones populated by many entities
    simultaneously)
    >>>
    I
    need many threads.
    I'm using JRockit's thin thread model on a Windows XP machine and am"only" able
    to get approximately 25000 threads at which point the JVM hangs withno diagnostic.
    I say "only" because at that point there seems to be plenty of heapspace left
    as well as Page File space left in the XP's Virtual Memory system.
    I'm using the following JVM command line:
    java -Xthinthreads -Xss32K -Xms256M -Xmx256M -Xallocationtype:global
    Surprisingly, by altering the heap size upward from 256MB to 512MBacutally causes
    the VM to hang with fewer threads (only 20000 or so)
    Using allicationtype:global and altering the stack size of the threadsseems to
    have little effect on the maximum number attainable.
    It seems the maximum number of threads attaible should be a functionof the size
    of the heap space, and the amount of physical and virtual memory limitson the
    system.
    My empirical evidence, however, seems to indicate there is some
    internal
    >>>
    VM limit.
    Can someone explain for me the implementation of the thin thread modeland its
    limitations w.r.t. the number of threads it can support?
    Thanks in advance for you help.

  • Illustrator won't run: "unable to set maximum number of files to be opened"

    I have an intel macbook pro (core duo with 2GB ram) and a copy of purchased adobe creative suite 2. Other applications in the suite like photoshop, acrobat, etc can run on my mac without any problem. But when I try to run illustrator, it just shows an error message "Unable to set maximum number of files to be opened" and quits. I also installed a trial version of illustrator cs3 and got the same problem. Can anyone help? Thanks.
    CC

    Hi, I realize this is an old thread but it was unanswered and the issue has come up again in a newer thread:
    http://forums.adobe.com/message/2534652
    If the original poster sees this, can you reply tin the new thread and let us know if you were ever to solve this problem?
    Thanks!

  • Create standby maximum number of logfiles for each thread

    The oracle doc states this equation for appropriate number of standby redo log file groups
    (maximum number of logfiles for each thread +1) * maximum number of threads
    How do you get the maximum number of logfiles for each thread and the max thread?
    Thanks!

    If you are running RAC you can, in theory, be running with a diferent count
    of Online Redo Logs in each thread (instance).
    However, normally, you would have the same number of Redo Logs in each
    thread.
    The theoretical max is prescribed at the CREATE DATABASE and can be
    changed with a CREATE CONTROLFILE. If you do an
    ALTER DATABASE BACKUP CONTROLFILE TO TRACE
    the sql script in the tracefile shows the maximum number of logs and members.

  • Maximum number of threads that can be spawned

    Hi
    What is the maximum number of threads that can be spawned from a 64-bit jvm with jdk 1.5? The application runs on
    SunOS 5.10 Generic_118833-24 sun4u sparc SUNW,Sun-Fire-480R
    Thanks

    Somewhere between about 10 and several hundred billion.
    A specific answer can be easily determined by you by actually writing a very small apps that spawns them and counts them.
    You might note that modern OSes limit the number of threads per app. In most or perhaps all unix variants you can change that limit. You can't increase that limit in java.
    Running the maximum number is very unlikely to be good idea however. Requiring that would suggest that the design is broken.

  • Can we change [maximum number of records per page] property at run time

    can we change [maximum number of records per page] property at run time in report 6i

    Ravi,
    I hope you are already done with this. In the invoice there is a nice example you can use on the xml blogs.
    You limit the number of lines per page when you use the xsl commands like this in your template:
    <xsl:variable name="lpp" select="number(13)"/>
    <?for-each@section:LIST_G_INVOICE?>
    <xsl:variable xdofo:ctx="incontext" name="invLines" select=".//G_LINES[LINE_TYPE='LINE']"/>
    <?for-each:$invLines?> <?if:(position()-1) mod $lpp=0?> <xsl:variable name="start" xdofo:ctx="incontext" select="position()"/>
    and then you have the table where you have the data
    <?for-each:$invLines?><?if:position()>=$start and position()<$start+$lpp?>
    and all your lines
    and then
    <?end if?><?end for-each?>

  • Reduce number of running thread under Linux

    Hello,
    How can reduce the number of running thread for coldfusion MX
    7.0.2 server under Linux (they are almost 30; )

    If you create a pool of any sort you will need a point where all requests for a resource from the pool must go via, and that piece of code could potentially become a bottle neck. But if you develop it well there will be a very small piece of code that is sychrnonized that will either put a request in a queue as there are no resources available, or it will provide the requested resource. As far as i am aware there is no safe way around this as you will have multiple threads requesting the resource.

  • How to control the number of running thread

    I need to maintain the number of running thread in the system or in a threadgroup, as too many running thread will make the system throughput drop tremendously because of the context swtich and memory problem. The threadgroup is not a solution as its active count is the number of the threads that are alive, it includes the thread being blocked as well. I don't know whether there is any way to control it without the use of an expensive monitor?
    Thanks for any help

    If you create a pool of any sort you will need a point where all requests for a resource from the pool must go via, and that piece of code could potentially become a bottle neck. But if you develop it well there will be a very small piece of code that is sychrnonized that will either put a request in a queue as there are no resources available, or it will provide the requested resource. As far as i am aware there is no safe way around this as you will have multiple threads requesting the resource.

  • Java.lang.IllegalStateException: Exceeded maximum number of waiting threads

    Hi all,
    I use coherence3.3.1,coherence work as hibernate L2 cache and meet following problem,could you help me check the problem?thanks.
    java.lang.IllegalStateException: Exceeded maximum number of waiting threads (Status=2)
         at com.tangosol.net.cache.OverflowMap$Status.waitForAvailable(OverflowMap.java:4029)
         at com.tangosol.net.cache.OverflowMap.prepareStatus(OverflowMap.java:2152)
         at com.tangosol.net.cache.OverflowMap.beginKeyProcess(OverflowMap.java:1873)
         at com.tangosol.net.cache.OverflowMap.getInternal(OverflowMap.java:580)
         at com.tangosol.net.cache.OverflowMap.get(OverflowMap.java:330)
         at com.tangosol.coherence.component.util.CacheHandler.getLease(CacheHandler.CDB:3)
         at com.tangosol.coherence.component.util.CacheHandler.getCachedResource(CacheHandler.CDB:10)
         at com.tangosol.coherence.component.util.CacheHandler.get(CacheHandler.CDB:1)
         at com.tangosol.coherence.component.util.SafeNamedCache.get(SafeNamedCache.CDB:1)
         at com.tangosol.coherence.hibernate.CoherenceCache.get(CoherenceCache.java:65)
         at org.hibernate.cache.StandardQueryCache.get(StandardQueryCache.java:105)
         at org.hibernate.loader.Loader.getResultFromQueryCache(Loader.java:2152)
         at org.hibernate.loader.Loader.listUsingQueryCache(Loader.java:2117)
         at org.hibernate.loader.Loader.list(Loader.java:2087)
         at org.hibernate.loader.custom.CustomLoader.list(CustomLoader.java:289)
         at org.hibernate.impl.SessionImpl.listCustomQuery(SessionImpl.java:1695)
         at org.hibernate.impl.AbstractSessionImpl.list(AbstractSessionImpl.java:142)
         at org.hibernate.impl.SQLQueryImpl.list(SQLQueryImpl.java:150)
         at org.hibernate.impl.AbstractQueryImpl.uniqueResult(AbstractQueryImpl.java:804)
    j

    Hi,
    Can you please provide the relevant coherence config files?
    thanks,
    -Rob

  • JRUN thread number

    Hello,
    I was looking for logs and the field "threadId".
    I've found that "JRPP-X" is for JRUN thread and the X is a
    number.
    My X increases, about +200 per day for 60k connections... So
    I'm wondering if it means that there are memory/thread leak or
    something like that...
    Thanks,
    Y.

    Your threads will fall down to the minhandler count on a
    server that is idle or lightly used. So, threads will go away. In
    short, the thread ID incrementing does not show any negative
    behavior by itself.

Maybe you are looking for