Re: Document Server Memory Leak Suspicion

  Chris ,

gives 3.3 a trie ?
>  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]
>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [email protected]
> For additional commands, e-mail: [email protected]