Re: Outrigger memory leak?

Greg Trasuk wrote:
> Hi Dan and John:
>
>         Sorry for the lack of response; I was out of the office on Friday.
> I've put some comments below.  Again, thank you for looking at the
> problem.
>
> Cheers,
>
> Greg.
>
> On Fri, 2007-01-05 at 19:11, Dan Creswell wrote:
>> So, the possible fly in the ointment is the harvester container aspect.
>>
>> Wondering how that interacts with outrigger and how that might be
>> different from the normal environment you (JM) run your tests in.
>>
> As I said earlier, my first suspicion was that Harvester was causing
> some oddities.  I tried to rule that out by running the Outrigger
> service standalone through the starter scripts in the starter kit.  I've
> still got the client running under Harvester, but I haven't come up with
> a plausible way that the client environment could cause a problem, so I
> haven't tried to run it standalone.  Perhaps I should try that.
>
>> Based on talk of not being able to drop-in replace outrigger with blitz,
>> it sounded like the plugin/container integration was some non-trivial
>> piece of work - more than just an inert wrapper anyways maybe.
>>
> My fault for causing the confusion; it's not a re-implementation issue,
> I just need to understand the config file to see if it needs tweaking
> (e.g. to put any files in the right directories).  There's a wrapper
> that will run any service written to conform to
> com.sun.jini.starter.ServiceStarter.
>
> So on Monday morning I'll be trying out Blitz to see if I get any
> different behaviour.  I guess the next step is to just take Harvester
> out of the picture by writing a non-Harvester test client and see what
> happens.
>
>> Dan.
>>
>> John McClain - Sun Microsystems, Inc. wrote:
>>> Well, I would have hoped that 1000 byte payloads would work. In the past
>>> I have run plenty of tests with 1000 byte payloads and tens of thousands
>>> of iterations (probably with bigger heaps though)....
>>>
> What would you call bigger heap, and what size should I need to hold few
> meg worth of entries? I've run it up to 512MB, and I still see the leak,
> it just takes longer.  Normally when I'm debugging I drop the heaps on
> all the containers down to 32MB or so just to keep everything in
> physical memory (couple services + client at 512MB max heap could get
> over 1.5GB).

Generally I just run with the default heap size, which seems to be
typically in the 200-600 MB range.

>>> Did the problem crop up in some new space client you are writing, or
>>> some existing client?
>>>
> It's actually the first application where I've used JavaSpaces.  So I
> assume I've done something wrong, it's just figuring out what.
>
>>> Very strange....
>>>
> Agreed.  By chance, does anything different happen under a transaction
> than if you use a null transaction?  I'm not currently providing a
> transaction.

Things get a lot more complicated with a non-null transaction, and there
are many more opportunities to leak objects (more objects, more tables,
more periodic checks, extra remote calls) - so generally I would expect
a memory leak to be more likely with a non-null transaction, not less
likely.

> <snip>



--
John McClain                                    [email protected]
Sun Microsystems, Inc.
Burlington, MA

And it is that way today. We are tricked by hope into starting
companies, beginning books, immigrating to this country and investing
in telecom networks. The challenges turn out to be tougher than we
imagined. Our excessive optimism is exposed. New skills are demanded.
But nothing important was ever begun in a prudential frame of mind.

         - David Brooks

===========================================================================
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