Re: Document Server Memory Leak Suspicion

and then trie to uses Cor's idea, open and closing 2 OO-services

On 2/11/2010 17:39, Fernand Vanrie wrote:
>  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]
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [email protected]
> For additional commands, e-mail: [email protected]