RE: [openorb-devel] Another notification leak resolved.

[J. S. E. <ev...@cp...>]

Lars,

At 10:56 AM 7/15/03 +0200, Lar...@pp... wrote:
>Scott,
>
>is your Notification load test independent from the rest of your own code?
>Would it be possible to contribute the stress test to the openorb source
>base?

No, the tests are part of my app server test framework and cannot easily be 
separated.  At one point I did take an existing notify example and modify 
it to make sure that the leaks were not in my code but the mods were real 
hacks and I don't believe I have them anymore.  It didn't take too much 
effort to use the existing structured event examples to create stress tests 
but the level of effort for a comprehensive test suite might be significant.

>I'm asking because I am more and more convinced that the Notification
>Service needs some serious modifications (or even a rewrite?), but I don't
>dare to even start before we have some tests to verify that I didn't break
>more than I fixed.

Prudent idea, IMHO.  Regression tests are life-saver (translation 
time-saver) when dealing with something complex like notify.  FWIW, I'd be 
willing to contribute test cases to a test suite if someone is willing to 
establish a framework for straightforward insertion of test cases.

Scott

>Lars
>
> > -----Original Message-----
> > From: J. Scott Evans
> > Sent: Friday, May 02, 2003 6:40 PM
> > To: ope...@so...
> > Cc: John Haynes; smi...@fe...
> > Subject: Re: [openorb-devel] Another notification leak resolved.
> >
> >
> >
> > Richard,
> >
> > At 04:20 PM 5/2/03 +0100, Richard Clark wrote:
> > >Scott,
> > >
> > >I've updated org.openorb.notify.Logger so that child loggers
> > created will use
> > >prefix logging so they shouldn't hang around. You can also
> > use --debug NONE to
> > >use null logging.
> > >
> > >You'll also need the CVS HEAD of the tools modules.
> >
> > Excellent, thanks for your efforts.  I ran an 8 hour load
> > test last night
> > (using my local patches) that effectively hammered the
> > notification service
> > (4 independent client threads each using 25 channels having
> > 25 pushers & 24
> > consumers per channel where each pusher pushes a
> > StructuredEvent to 24
> > consumers - repeat pusher/consumer connects, event push, and
> > disconnects as
> > fast as possible for 8 hours non stop).  The test passed and
> > the memory
> > usage fluctuated, sometimes by +- 10 MB, but showed no
> > indication of any
> > measurable leaks.  I'll be running 72-120 hour load tests
> > over the next
> > week or so to further verify no leaks (at least in the
> > classes used in the
> > test).  Thanks for quick responses and patches for these problems!
> >
> > Scott
> >