Re: [api-dev] Document Server Memory Leak Suspicion
Hi Chris, On 02.11.2010 13:40, Chris Rider wrote: 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! We still don't have enough information, or perhaps not the right one. OOo in general definitely does not have a memory leak of that kind - you wouldn't be the first to find it in case of. I know that OOo is used as a server in a lot of installations without such huge problems. So there must be a particular issue that is special for your setup. So let's summarize and see where we can make progress. We should try to describe everything exactly as possible. You are talking about a document server and a DocumentLoader. The latter seems to be a C++ application and the former seems to be an instance of OOo that is talking with the C++ application though a remote UNO bridge. The DocumentLoader seems to use this instance of OOo to load a ppt file and then it seems that something is eating up your memory. Is that the correct picture? If not, can you describe it better? Especially we need to know most exactly how OOo is used in this scenario. Next question - this something that eats up your memory - did you verify that it is the OOo process whose memory consumption goes through the roof? Another question: did you try the same with other kinds of documents (not ppt)? Regards, Mathias -- Mathias Bauer (mba) - Project Lead OpenOffice.org Writer OpenOffice.org Engineering at Oracle: http://blogs.sun.com/GullFOSS Please don't reply to nospamfor...@gmx.de. I use it for the OOo lists and only rarely read other mails sent to it. - To unsubscribe, e-mail: dev-unsubscr...@api.openoffice.org For additional commands, e-mail: dev-h...@api.openoffice.org
Re: [api-dev] Document Server Memory Leak Suspicion
Morgen Mathias, Nur falls es dich interessiert: Deine Mail kommt bei mir als von gestern 18:43 an... Thomas On 02.11.2010 18:43, Mathias Bauer wrote: Hi Chris, On 02.11.2010 13:40, Chris Rider wrote: 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! We still don't have enough information, or perhaps not the right one. OOo in general definitely does not have a memory leak of that kind - you wouldn't be the first to find it in case of. I know that OOo is used as a server in a lot of installations without such huge problems. So there must be a particular issue that is special for your setup. So let's summarize and see where we can make progress. We should try to describe everything exactly as possible. You are talking about a document server and a DocumentLoader. The latter seems to be a C++ application and the former seems to be an instance of OOo that is talking with the C++ application though a remote UNO bridge. The DocumentLoader seems to use this instance of OOo to load a ppt file and then it seems that something is eating up your memory. Is that the correct picture? If not, can you describe it better? Especially we need to know most exactly how OOo is used in this scenario. Next question - this something that eats up your memory - did you verify that it is the OOo process whose memory consumption goes through the roof? Another question: did you try the same with other kinds of documents (not ppt)? Regards, Mathias - To unsubscribe, e-mail: dev-unsubscr...@api.openoffice.org For additional commands, e-mail: dev-h...@api.openoffice.org
Re: [api-dev] Document Server Memory Leak Suspicion
Mathias, You're correct in all your statements. We are starting the document server like this: /opt/openoffice.org3/program/soffice.bin -accept=socket,host=localhost,port=2083;urp;StarOffice.ServiceManager -nolockcheck -nologo -impress -norestore -invisible Our DocumentLoader then is the compiled cxx that calls LoadComponentFromURL() and all this works. When we are switching from the current PPT to the next PPT the DocumentLoader calls the close() function (which is logged so we see it) and then exits. A new DocumentLoader then starts all over and does a new LoadComponentFromURL(). The entire time we are watching the soffice.bin process using top and the memory usage just continues to go up. Sincere thanks! -Chris On 11/02/2010 01:43 PM, Mathias Bauer wrote: Hi Chris, On 02.11.2010 13:40, Chris Rider wrote: 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! We still don't have enough information, or perhaps not the right one. OOo in general definitely does not have a memory leak of that kind - you wouldn't be the first to find it in case of. I know that OOo is used as a server in a lot of installations without such huge problems. So there must be a particular issue that is special for your setup. So let's summarize and see where we can make progress. We should try to describe everything exactly as possible. You are talking about a document server and a DocumentLoader. The latter seems to be a C++ application and the former seems to be an instance of OOo that is talking with the C++ application though a remote UNO bridge. The DocumentLoader seems to use this instance of OOo to load a ppt file and then it seems that something is eating up your memory. Is that the correct picture? If not, can you describe it better? Especially we need to know most exactly how OOo is used in this scenario. Next question - this something that eats up your memory - did you verify that it is the OOo process whose memory consumption goes through the roof? Another question: did you try the same with other kinds of documents (not ppt)? Regards, Mathias - To unsubscribe, e-mail: dev-unsubscr...@api.openoffice.org For additional commands, e-mail: dev-h...@api.openoffice.org
Re: [api-dev] Document Server Memory Leak Suspicion
@Cor, Thanks for following up for more details... We tried using 3.3 this morning and it didn't really work with our DocumentLoader program and seemed a bit buggy-ish ~~ so maybe a no-go there (at least until 3.3. is official). Yeah, you're right... the shakeup is a whole different subject... I suppose I am also a little apprehensive about the big corporation coming in on this great open souce resouce. I hope it all irons out for everyone involved ~ not just us users. Just wanted to say that since I may have come across the wrong way when I mentioned that before! :) -Chris On 11/02/2010 05:55 PM, Cor Nouws wrote: Hi Chris, Chris Rider wrote (02-11-10 19:10) We came up with a process that regularly restarts it before the memory usage becomes too high, but this is not 100% desirable in our particular application. We can't have any kind of interruption in how we display content (brief flashes or anything). Also, it's challenging to monitor the memory usage of this one particular process, programatically in our application. Also, these aren't exactly thin clients, but they are running a tight margin with resources, as we use them for quite intensive media (1080p) among other things ~ so it's really not the best solution to have to constantly monitor and check things in this manner, or run redundant processes though you did provide a smart workaround there, Cor, and we appreciate the suggestion! Thanks, Obviously, I'll check my contact to see if I can provide more details. Looking at your comment above, I have the idea that it may have more in it, than I was able to explain right now. If the document server has some issue with leaking memory, it should at least be addressed in principle IMHO. Memory leaks are pretty serious bugs, aren't they? Yip. I've heard rumors of a shakeup at Oracle / OpenOffice I hope we the users aren't going to bear the brunt of it! That's a totally different subject. And I fully agree with you of course! Best regards, Cor - To unsubscribe, e-mail: dev-unsubscr...@api.openoffice.org For additional commands, e-mail: dev-h...@api.openoffice.org
Re: [api-dev] Document Server Memory Leak Suspicion
On 11/03/10 13:47, Chris Rider wrote: We are starting the document server like this: /opt/openoffice.org3/program/soffice.bin -accept=socket,host=localhost,port=2083;urp;StarOffice.ServiceManager -nolockcheck -nologo -impress -norestore -invisible Somewhat unrelated, please note that running soffice.bin directly is not supported. You should always run soffice (which will internally call soffice.bin). -Stephan - To unsubscribe, e-mail: dev-unsubscr...@api.openoffice.org For additional commands, e-mail: dev-h...@api.openoffice.org
Re: [api-dev] Document Server Memory Leak Suspicion
@Stephan, Thanks for the suggestion... we changed out code to run the script instead of the binary directly. Also, this hasn't changed our issue (as was probably expected)... even after we take down / stop the PPT file, top still reports massive memory usage for the soffice process. -Chris On 11/03/2010 09:17 AM, Stephan Bergmann wrote: On 11/03/10 13:47, Chris Rider wrote: We are starting the document server like this: /opt/openoffice.org3/program/soffice.bin -accept=socket,host=localhost,port=2083;urp;StarOffice.ServiceManager -nolockcheck -nologo -impress -norestore -invisible Somewhat unrelated, please note that running soffice.bin directly is not supported. You should always run soffice (which will internally call soffice.bin). -Stephan - To unsubscribe, e-mail: dev-unsubscr...@api.openoffice.org For additional commands, e-mail: dev-h...@api.openoffice.org - To unsubscribe, e-mail: dev-unsubscr...@api.openoffice.org For additional commands, e-mail: dev-h...@api.openoffice.org
Re: [api-dev] Document Server Memory Leak Suspicion
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. 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 chris.ri...@messagenetsystems.com Organization: MessageNet Systems, Inc. To: _OpenOffice API Developers List dev@api.openoffice.org (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: dev-unsubscr...@api.openoffice.org For additional commands, e-mail: dev-h...@api.openoffice.org - To unsubscribe, e-mail: dev-unsubscr...@api.openoffice.org For additional commands, e-mail: dev-h...@api.openoffice.org
Re: [api-dev] Document Server Memory Leak Suspicion
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 chris.ri...@messagenetsystems.com Organization: MessageNet Systems, Inc. To: _OpenOffice API Developers List dev@api.openoffice.org (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
Re: [api-dev] 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 chris.ri...@messagenetsystems.com Organization: MessageNet Systems, Inc. To: _OpenOffice API Developers List dev@api.openoffice.org (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
Re: [api-dev] 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 chris.ri...@messagenetsystems.com Organization: MessageNet Systems, Inc. To: _OpenOffice API Developers List dev@api.openoffice.org (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
Re: [api-dev] 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 chris.ri...@messagenetsystems.com Organization: MessageNet Systems, Inc. To: _OpenOffice API Developers List dev@api.openoffice.org (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.
Re: [api-dev] Document Server Memory Leak Suspicion
We came up with a process that regularly restarts it before the memory usage becomes too high, but this is not 100% desirable in our particular application. We can't have any kind of interruption in how we display content (brief flashes or anything). Also, it's challenging to monitor the memory usage of this one particular process, programatically in our application. Also, these aren't exactly thin clients, but they are running a tight margin with resources, as we use them for quite intensive media (1080p) among other things ~ so it's really not the best solution to have to constantly monitor and check things in this manner, or run redundant processes though you did provide a smart workaround there, Cor, and we appreciate the suggestion! If the document server has some issue with leaking memory, it should at least be addressed in principle IMHO. Memory leaks are pretty serious bugs, aren't they? I've heard rumors of a shakeup at Oracle / OpenOffice I hope we the users aren't going to bear the brunt of it! Chris On 11/02/2010 12:11 PM, Cor Nouws wrote: Hi Chris, Chris Rider wrote (02-11-10 16:47) 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. I remember that someone told me setting up a service with OpenOffice.org: He had two instances running, constantly checking the (memory) state of the first. When that got to bad, using the second and restarting the first. Of course this all automatically. And it worked without probs. Regards, Cor - To unsubscribe, e-mail: dev-unsubscr...@api.openoffice.org For additional commands, e-mail: dev-h...@api.openoffice.org
Re: [api-dev] Document Server Memory Leak Suspicion
Hi Chris, Chris Rider wrote (02-11-10 19:10) We came up with a process that regularly restarts it before the memory usage becomes too high, but this is not 100% desirable in our particular application. We can't have any kind of interruption in how we display content (brief flashes or anything). Also, it's challenging to monitor the memory usage of this one particular process, programatically in our application. Also, these aren't exactly thin clients, but they are running a tight margin with resources, as we use them for quite intensive media (1080p) among other things ~ so it's really not the best solution to have to constantly monitor and check things in this manner, or run redundant processes though you did provide a smart workaround there, Cor, and we appreciate the suggestion! Thanks, Obviously, I'll check my contact to see if I can provide more details. Looking at your comment above, I have the idea that it may have more in it, than I was able to explain right now. If the document server has some issue with leaking memory, it should at least be addressed in principle IMHO. Memory leaks are pretty serious bugs, aren't they? Yip. I've heard rumors of a shakeup at Oracle / OpenOffice I hope we the users aren't going to bear the brunt of it! That's a totally different subject. And I fully agree with you of course! Best regards, Cor -- - giving openoffice.org its foundation :: The Document Foundation - - To unsubscribe, e-mail: dev-unsubscr...@api.openoffice.org For additional commands, e-mail: dev-h...@api.openoffice.org
