From what I could tell it was the entity bean locking and CMR updates that caused this to happen. The operations I would perform to get another process running were using reporting functions that bypass entity beans (no way I'm going to try to use entity beans to report on 10,000 out of 3million entity beans).
My application has been painfully slow because of this so yesterday I completely stripped CMR from the system. This was very easy to do as I have ints as primary keys for all my objects and ejbCreate takes FooData and the CMR objects as parameters...
- Change setBar and getBar to set/return int
- Add getBarOb() to return the related object
- Remove CMR objects from ejbCreate and ejbPostCreate
- Fix uses of create to remove CMR objects and call appropriate FooData.set* methods instead
- Fix finder methods to take int instead of the object
The only tricky part was when I had a finder query that utilitized the CMR relationship to do cross table queries. In my instance I simply implemented the select in JDBC as a home method and returned the ints. Also, making sure to throw ObjectNotFoundException so I didn't have to change logic throughout the code.
This works well for simple data types (integer, real, string, etc) which are the same across DBs but not so well for things like boolean (I forcefully map String types to VARCHAR when I need to query them for reporting so that isn't an issue). I had a case where I had a CMR boolean field to check and I chose to leave the finder method intact and perform a check on the objects via getBarOb().getSomeFlag() on the results returned.
The short of this is I now have a load of 1.0 instead of 8 on my little box and application response is wonderful. The JVM is also less than 75M where it was around 280M (I set the heap at 256M). And both processors are being used (totaly java process load exceeds 1 cpu when needed).
BTW has anyone else noticed Sun JVM 1.4.1 corrupting the heap and crashing on x86 Linux?
Brian Macy
Fredrik Lindgren wrote:
This could also be due to synchronization somewhere in your code. Something to look for is heavy usage of System.out. Writing using System.out is synchronized and can be really slow if you have the console open.
I've seen this once on a really powerful AIX cluster (Jboss was not part of that setup though) When tracking the problem we added more trace messages to System.out. That did not help :-)
I hope this helped
/Fredrik Lindgren
Alwyn Schoeman wrote:
I get the idea that this is Sparc specific problem, anyone with sparc success?On Fri, Oct 11, 2002 at 09:25:24AM +0200, [EMAIL PROTECTED] wrote:Jboss (3.0.2 at least) is using both of our 2 CPUs on 2.2.* SuSE kernel on intel.
On Fri, Oct 11, 2002 at 12:06:23PM +0800, Alwyn Schoeman wrote:
Hi,
I'm running JBoss 3.0.3 on a Sun Fire 880 with 8 cpu's. Even though I
have about 450 threads going it uses only 1 cpu and not very well at
that. I have tried all the JVM options for 1.4.1, but no difference.
Anyone have any ideas?
--
Alwyn Schoeman
SMART Money Inc.
"The clock on the wall keeps moving, time stands still...
No matter how the dice may fall, someone else always gets to call the number..."
-- MVH Marius Kotsbak Boost communications AS ------------------------------------------------------- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf _______________________________________________ JBoss-user mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-user------------------------------------------------------- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf _______________________________________________ JBoss-user mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-user
------------------------------------------------------- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf _______________________________________________ JBoss-user mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-user
