Re: Outrigger memory leak?

Greg Trasuk <[email protected]> Wed, 3 Jan 2007 14:36:37 -0500
Newsgroups gmane.comp.java.sun.javaspaces
Message-ID <1167852997.5763.139.camel@cameron>
Hi Dan:

        Thanks for responding; see interspersed comments.

        I noted your web page entry regarding Blitz's caching strategy, and the
fact that running with reduced heap size will subvert it, so you have to
match the cache size to heap size.  However I can't see any mention of a
similar requirement with Outrigger.

        I take it you haven't seen this type of thing before (at least with
Blitz)?

Cheers,

Greg.

On Wed, 2007-01-03 at 14:01, Dan Creswell wrote:
> Gregg Wonderly wrote:
> > Greg Trasuk wrote:
> >>         Am I missing something in the configuration?  The problem is
> >> independent of whether Outrigger is run under Harvester or from the
> >> Launch-All script in the starter kit.  I haven't found any other bug
> >> reports, and I find it hard to believe I've found a bug in a mature
> >> product.  Any suggestions?
> >
> > Can you try the same application with Blitz to see if there is any
> > difference?
> > I'd guess that you are not using enough heap.  Are you configuring
> > -mx512m on
> > the command line, or how are you starting the JVM that you think has a
> > 512M heap?
> >
>
> Well, I was thinking about that tactic myself but you'd need to setup
> Blitz's cache sizes and stuff to make sure it all fits into available
> memory.
>
> Otherwise you could see what looks like a leak but is just being
> provoked by mis-configuration.
>
> I can help out with that but:
>
> "the Outrigger instance runs out of heap after
> about 2100 iterations with a payload size of 250e3 bytes."
>

Betraying my engineering roots; read the above as 250,000 bytes.

> I wasn't sure if that is a size in hex or a typo?????
>
> It could be heap but I'm not clear why as a quick look at the code
> suggests there's not a huge number of entry's lying around in the space
> at any moment.  Unless of course we've got some backlog of entry's
> forming somehow which I didn't think was likely for this case.
>

That's exactly my issue; the Space is being used for communications
rather than storage, so I would expect very little sustained memory
usage, no matter how big the entries are.  I'd expect the VM to grow
(i.e soak memory from the operating system) as needed for burst
capacity, but the actual heap used should stay relatively small.

> Dan.

===========================================================================
To unsubscribe, send email to [email protected] and include in the body
of the message "signoff JAVASPACES-USERS".  For general help, send email to
[email protected] and include in the body of the message "help".

To view past JAVASPACES-USERS postings, please see:
http://archives.java.sun.com/archives/javaspaces-users.html