| Re: [stellation-res] Latest checkin *does* run the unit tests - with one change |
On Wed, Aug 14, 2002 at 11:54:33AM +0000, Mark C. Chu-Carroll wrote: > > I am using Alan Cox kernels that do not allow to allocate more memory > > than you really have. I think you are using RedHat stock kernels which > > allow overcommit: the process can allocate as much memory as it wants as > > long as it doesn't use it ;) This can cause out-of-memory when the > > process really dirties too many pages. With strict overcommit control > > that does not happen - a request to allocate more memory than is > > available fails right away. > > There's still a JVM memory restriction, Not for the unit tests. I will set it in build.xml and see what happens. > which is independent of the kernel. > (Meaning that it's normally set so that it should kick in before you've used > so much memory that you'll run out. But when you consider the Eclipse 256M > max heap, plus the same for the JVM running JUnit under Eclipse, plus the, I > think, 128M max heap for the server... Yeah. You can trip that limit. I wasn't running it under Eclipse. I was running them on the command line using the ant target for junit. > > > Gag! I'll try to look at that. Something is *seriously* wrong there. I'm > > > having a hard imagining where 1000 threads could be coming from! > > > > > > Out of curiousity... Do you see the same kind of out-of-control thread > > > stuff running from the command line? Or is it just when run from the > > > unittest framework? > > > > It happens only with the unittest framework right now because it uses a > > single jvm process for all operations. > > Does the unit test framework close the workspace between invocations? I am calling Svc.run . That is the "frontier". I don't know if that invocation ties the loose threads or not... > What I'm > wondering is if the old invocations of svc aren't fully terminating, They are, because they return a success value - 0. > in which > case you'd see a communication core thread, plus the message queue thread > pool, for each of the invocations. The default message pool is 5 threads, > producing, I think, 8 client-side threads per invocation. (Hmmm... I wonder > if the message handler thread pool is terminating threads correctly on > engine shutdown... I'll check that.) > > This wouldn't explain 1000 threads, 5 tests * (15 checkins + 15 checkouts + 1 list version + 5 adds) * 8 threads - we are pretty close > > > (Unfortunately, I'm home with the baby today, > > > > Get him better soon! > > *Her*. My apologies to the young lady! > She's a lot better today... Yesterday, she was running a high fever; > today, the fever is barely detectable. (less than 1 degree F.) That is good. florin -- "If it's not broken, let's fix it till it is." 41A9 2BDE 8E11 F1C5 87A6 03EE 34B3 E075 3B90 DFE4
Attachment:
pgpzHG9f2hnL1.pgp
Description: PGP signature