I'm experiencing similar symptoms on MacOS X 10.1.3. The JVM behaves a bit better though, because JBoss is the only impacted process.
Anyway, multiple successive deploys seems to consume memory. At some point I start getting: 11:08:28,432 ERROR [STDERR] java.lang.OutOfMemoryError 11:08:28,433 ERROR [STDERR] <<no stack trace available>> messages on the console. Our Win2k developers haven't noticed anything because they usually have to cycle JBoss down and up in order to redeploy anyway, because Windows won't let them overwrite open files. This is from CVS HEAD as of about 24hrs ago BTW, but I think this problem has been around for awhile. Steve C. On Friday, April 12, 2002, at 08:51 AM, Mark Gulbrandsen wrote: > > FYI, > > Maybe this has already been posted, but I'll post it again. > > The deployer on cvs HEAD has a memory problem (I think). If I don't pass > any JAVA_OPTS to run.sh via the environment, then redeploying is > seriously > broken. After the third redeploy *with out fail* jboss runs after every > last mb of ram and swap. I have to shut it down before it brings my > system > to its knees, and I have over 600 mb of ram and 512 mb of swap. If I > pass > memory options such as -Xms128M -Xmx256m, then no problem exists at all. > BTW, this also happens on another box in my office that has 4GB of RAM, > but limiting the heap seems to solve it. I'd love to send more > information > regarding this, but I'm not sure what you (developers) want. I'd look > into > it, but I can't get into the code just yet (maybe in a few weeks). > > > > BTW, we're running SuSE Linux 7.3 with SUN JDK1.3.1. > > mark@mark:~/usr/src/jboss-cvs/bin> java -version > java version "1.3.1" > Java(TM) 2 Runtime Environment, Standard Edition (build 1.3.1-b24) > Java HotSpot(TM) Client VM (build 1.3.1-b24, mixed mode) > _______________________________________________ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development