Re: Document Server Memory Leak Suspicion

  FYI, we are using 3.2.1

Chris


On 11/02/2010 12:02 PM, Fernand Vanrie wrote:
>  Chris ,
>>  Thanks for the comment/insight... I'll try to investigate, but not 
>> hopeful.
>>
>> It happens once a document is closed, seemingly (could be on open, 
>> too)... and each subsequent/repeated opening of the file takes longer 
>> and longer. It really just seems like the memory isn't being cleared 
>> on close, is my best guess.
> The memory is not handled by the document, but is suppose every object 
> can cause a leak, in fact only closing OO itself is clearing all the 
> used memory. So trie to find witch objects are leaking. I found a lot 
> of emprovements in the latest versions, did you trie to use the latest 
> 3.2 or 3.3 ?
>
>  For the record, the ImageControls are no longer leaking sinds 3.2 :-)
>
> Fernand
>
>
>
>
>>
>> Chris
>>
>>
>> On 11/02/2010 11:12 AM, Fernand Vanrie wrote:
>>> Chris ,
>>>
>>> I have no experience with server applications but in the past, i 
>>> found some "leaks" when using "ImageControls", its not necerarly the 
>>> document itselfs who leaks, Trye to reproduce the operation on a 
>>> local machine ad see when or where the memory eating starts ?
>>>
>>> Fernand
>>>>  I hope this is an active mailing list ~ we have a serious issue 
>>>> with the document server and are trying to track down some more 
>>>> knowledge that might exist about it.
>>>>
>>>> I have new information from further testing, but here's a quick 
>>>> summary:
>>>> We have a program that calls the document server to load a PPT file 
>>>> (as explained below). That goes fine, and then we call it to close 
>>>> the file after some time... also goes fine -- mostly. The file will 
>>>> close, but then the memory continues to be eaten up by document 
>>>> server until the machine becomes non-responsive.
>>>>
>>>> We've run strace and can't find anything.
>>>> We're calling the server over port 2803.
>>>> We're calling the close method (which I've learned also calls 
>>>> dispose, etc.).
>>>>
>>>> We've got hundreds of products at customers and some are beginning 
>>>> to doubt OpenOffice as a platform... please help!
>>>> Chris
>>>>
>>>> -------- Original Message --------
>>>> Subject:     Document Server chaos -- not talking properly, 
>>>> intermittently
>>>> Date:     Tue, 26 Oct 2010 15:46:23 -0400
>>>> From:     Chris Rider <[email protected]>
>>>> Organization:     MessageNet Systems, Inc.
>>>> To:     _OpenOffice API Developers List <[email protected]>
>>>>
>>>>
>>>>
>>>>  (I previously posted something about Document Loader - that is now
>>>> revised and different, hence this post ~~ You'll find this post much
>>>> more informative, I hope!)
>>>>
>>>> Please forgive me for causing any confusion... I was put on this 
>>>> project
>>>> after another engineer here took another position, so I've been 
>>>> playing
>>>> catch-up on understanding it fully enough to at least put out a lucid
>>>> question to this community. Your patience and time is very much
>>>> appreciated!!!
>>>>
>>>> The previous developer wrote a C++ program that we call 
>>>> DocumentLoader,
>>>> that talks to the Document Server, and loads a PPT file. The Loader 
>>>> file
>>>> has been through extensive testing and debugging, so I/we HIGHLY doubt
>>>> the problem lies within it (been wrong before though!).
>>>>
>>>> Typically, these PPT files are setup as "slideshows" that auto-advance
>>>> their slides and usually repeat/rotate, as managed by our own 
>>>> product (a
>>>> type of multimedia messaging solution). Just for the sake of example,
>>>> this might be a "daily announcements" slide-show set to display 
>>>> (amongst
>>>> other types of messages) every 5 minutes (the other types of messages
>>>> would show the remainder of the time, rinse, repeat, etc.)
>>>>
>>>> So here's the problem......
>>>> Whenever DocumentLoader tells the Document Server to take down the PPT
>>>> file, it appears to; but when it comes time to load it to display it
>>>> again, it will - seemingly without problem... except that the 
>>>> machine's
>>>> memory keeps getting sucked down (the machine that's running the 
>>>> server
>>>> program). And, each time it cycles through (loads), there is about
>>>> one-second added to the load time. So a PPT that normally takes 
>>>> about 2
>>>> seconds to load, by the 6th time, takes like 8 seconds. And to make
>>>> matters worse, once we hit about a dozen or so loads, the machine
>>>> practically becomes non-responsive until we restart it.
>>>>
>>>> Also, (more just to see my debugging logic) we occassionally see
>>>> multiple instances of the DocumentLoader program (like 20 or more)
>>>> trying to load the same PPT file. I figure this is "normal"
>>>> in-so-much-as the loader is trying to talk the server into loading 
>>>> that
>>>> PPT (in the timed loop I described above), and the server is 
>>>> failing for
>>>> whatever reason to either respond to the loader and/or actually 
>>>> load the
>>>> file.
>>>>
>>>> I've been consulting with the previous engineer, as well as another
>>>> programmer here, and there is some agreement that there could be a
>>>> memory leak in the server program. It is very hard to debug, 
>>>> because we
>>>> have this deployed on hundreds of machines, and only a handful or so
>>>> behave this way ~ seemingly randomly, at that.
>>>>
>>>> I've not been able to find much info about this "server" ~~ can anyone
>>>> enlighten me?
>>>> Furthermore, is this a known issue of any kind?
>>>>
>>>> Even if just to say "welcome" (I'm new to the list), I'd appreciate 
>>>> any
>>>> ideas!!!  :)
>>>>
>>>> Humbly,
>>>> Chris
>>>>
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: [email protected]
>>>> For additional commands, e-mail: [email protected]
>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: [email protected]
>>> For additional commands, e-mail: [email protected]
>>>
>>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: [email protected]
>> For additional commands, e-mail: [email protected]
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [email protected]
> For additional commands, e-mail: [email protected]
>
>