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
View the original post :
http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3878908#3878908
Reply to the post :
http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3878908
-------------------------------------------------------
This SF.Net email is sponsored by Oracle Space Sweepstakes
Want to be the first software developer in space?
Enter now for the Oracle Space Sweepstakes!
http://ads.osdn.com/?ad_id=7412&alloc_id=16344&op=click
_______________________________________________
JBoss-user mailing list
JBoss-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/jboss-user
