2 Replies Latest reply on Aug 21, 2005 6:00 PM by rleeuk

    Bad, bad JBOSS - too many threads

    przemekd

      We're currently using JBOSS 3.2.5 on Linux Debian 2.4.28 and we've noticed some serious architectural problem: every entity bean has it's (synchronization) thread (Standard ejb 2.x container with commit option D and NoLock policy). This is fragment of dump after SIGQUIT:

      "Thread-313" daemon prio=1 tid=0x0x8c81c0e8 nid=0x5a44 waiting on monitor [965ff000..965ff8ac]
      at java.lang.Thread.sleep(Native Method)
      at org.jboss.ejb.plugins.EntitySynchronizationInterceptor$ValidContextsRefresher.run(EntitySynchronizationInterceptor.java:586)
      at java.lang.Thread.run(Thread.java:536)

      "Thread-312" daemon prio=1 tid=0x0x8c43f088 nid=0x5a3a waiting on monitor [967ff000..967ff8ac]
      at java.lang.Thread.sleep(Native Method)
      at org.jboss.ejb.plugins.EntitySynchronizationInterceptor$ValidContextsRefresher.run(EntitySynchronizationInterceptor.java:586)
      at java.lang.Thread.run(Thread.java:536)

      "Thread-311" daemon prio=1 tid=0x0x8c8893f8 nid=0x5a39 waiting on monitor [969ff000..969ff8ac]
      at java.lang.Thread.sleep(Native Method)
      at org.jboss.ejb.plugins.EntitySynchronizationInterceptor$ValidContextsRefresher.run(EntitySynchronizationInterceptor.java:586)
      at java.lang.Thread.run(Thread.java:536)

      "Thread-310" daemon prio=1 tid=0x0x8c804490 nid=0x5a38 waiting on monitor [96bff000..96bff8ac]
      at java.lang.Thread.sleep(Native Method)
      at org.jboss.ejb.plugins.EntitySynchronizationInterceptor$ValidContextsRefresher.run(EntitySynchronizationInterceptor.java:586)
      at java.lang.Thread.run(Thread.java:536)

      (... and so on)

      We are using currently about 270 entity beans, our project is still being developed - it may easly become bigger.

      So far, so good, now the bad things:
      our OS (an many others I think), or JVM crashes (OutOfMemoryError)when too many threads are created. We have tested with small java app, that increasing -Xmx parameter decreases maximal number of threads that could be created. There is almast no dependecy with other parameters (i.e. -Xss). For example:
      java -server -Xmx1024m -Xss127k TTest -> gives about 434 threads
      java -server -Xmx900m -Xss127k TTest -> gives about 497 threads
      java -server -Xmx800m -Xss127k TTest -> gives about 547 threads


      We are almost convinced that there is some bug of JVM that we cannot more threads when -Xmx is larger.
      That behaviour of JVM was tested with:
      Linux jdk 1.4.0_03-b04,
      Linux jdk 1.4.2_08-b03,
      Linux jdk 1.5.0_03-b07
      Win XP jdk 1.4.2_08-b03.


      Jboss seems to crash too because of this strange behaviour (limited number of threads, user limits are 'unlimited'). As I said, our project is rather big - we would have a lot of work to do if we would have to move to other "persitency manager" (like Hibernate or something).


      Is there any chance to fix this problem? How can we limit number of threads in JBOSS (maybe EntitySynchronizationInterceptor should deal with group of entity beans)?


      best regards,
      Przemek