Apache OpenOffice (AOO) Bugzilla – Full Text Issue Listing
|Summary:||soffice/some processes exit delayed after database access|
|Component:||code||Assignee:||AOO issues mailing list <issues>|
|Status:||ACCEPTED ---||QA Contact:|
|Issue Type:||DEFECT||Latest Confirmation in:||---|
Description fkater 2002-10-09 11:25:23 UTC
Hi, when I open a new writer doc, view any/the current data sources (f4), open the table (spreadsheet) and then *close* this doc (which was the last soffice app started) then soffice disappears from screen but some processes still continue for about 1 minute (I am working with gentoo-linux on a pentIII with 256MB RAM and UDMA5). This prevents from starting soffice again. This doesn't happen if I click 'exit' (instead of 'close'). In this case all processes die at once. Thank You.
Comment 1 Frank Schönheit 2002-10-09 12:20:29 UTC
Felix, sorry, I am not yet clear about the steps you are doing. What I (think I) understood is: * you open a writer doc * you open the data source browser (F4) * you display a table therein (belonging to a spreadsheet data source?) * you open a (_the_?) spreadsheet document. Did you close the writer doc in the meantime? Not sure if it describes the complete process. Can you perhaps add a step-by-step description? One thing I need to mention is that "Close" for the last window and "Exit" are different by design. When you choose "Close", the main process stays alive. In case you start an office again in this time, this new process should simply delegate it's task (probably opening a new document) to the old process, and die. When you choose "Exit", the process is terminated immediately. This then has nothing to do with databases at all. Is it possible that this is what you encountered? Does your problem really depend on database access? What do you mean with "prevents from starting" - what do you do there?
Comment 2 fkater 2002-10-09 12:57:03 UTC
What I did is: * I open a writer doc * I open the data source browser (F4) * I display a table therein (belonging to a spreadsheet data source) * I click on File/Close * soffice closes and disappears from screen (but the processes keep alive for about 1 minute) * I try to restart soffice but it doesn't start (because of the processes) * After 1 minute I can start soffice as usual. Imagine people who don't know anything of processes and try to restart soffice but can't... All this does not happen if I click "exit" instead of "close" - so this isn't generally so if you use database access. I agree that close and exit are different things but they should not behave that differently in case you close the last running soffice app. In this case close and exit should behave the same - but they don't. This difference appeared to me the first time I used database access.
Comment 3 Frank Schönheit 2002-10-09 13:14:56 UTC
Felix, thanks for the explanation. Still some questions (: * Does the same happen when you display a dBase instead of a spreadsheet table? * Does the same happen when you do not display a table in the data source browser? * Does the same happen when you do not open the data source browser at all?
Comment 4 fkater 2002-10-09 15:34:40 UTC
Hi, * Does the same happen when you display a dBase instead of a spreadsheet table? Sorry, I can't really test it right now basicly because I've got no time but also because I had my first crash of soffice ever after I had saved my spreadsheet into dbase and then wanted to delete the old source and add the new dbase one... (this is another issue) * Does the same happen when you do not display a table in the data source browser? Yes. * Does the same happen when you do not open the data source browser at all? No. But let me add something non database related: In general, if I click on 'exit' the menu freezes for a second and THEN the menu and the window close. I guess that this is because in meanwhile all processes are killed. However, if I click 'close' the menu and window close AT ONCE - and some time later the processes are killed in the background. So the user doesn't see that there is still some processes running (therefore you can't start soffice). So maybe all this issue could be solved if 'closing' would behave like exiting (in case that there is no other app open) or if there would be a window telling that processes are about to shut down.
Comment 5 fkater 2002-10-09 15:40:46 UTC
Additional thing to be more precise: In general, if I click on 'exit' the menu freezes for about ONE OR TWO seconds and THEN the menu and the window close. I guess that this is because meanwhile all processes are killed. However, if I click 'close' the menu and window close AT ONCE - and about FIVE seconds later all processes are killed in the background. With the database access these FIVE seconds turn into ONE MINUTE. So, the database related thing is why it takes so much longer.
Comment 6 dirk.grobler 2002-12-19 10:59:02 UTC
marc, could you try to reproduce the issue. Thanks.
Comment 7 marc.neumann 2003-01-14 11:20:09 UTC
Hi, I can reproduce it. This is a problem with the connection pooling. If you turn of the connection pooling under TOOLS/OPTIONS/DATASOURCE/CONNECTION POOLING that this behaviour doesn't corrure anymore. Bye Marc
Comment 8 Frank Schönheit 2003-01-14 12:40:07 UTC
Have to discuss without Mathias Bauer (cc'ing him) the alternatives we have here. Felix: the workaround would be to disable connection pooling for spreadsheet data sources in the options mentioned by Marc.
Comment 9 Frank Schönheit 2003-01-15 12:32:49 UTC
fs->mba: I talked to Niklas, according to him, the Calc SDBC driver should easily be able to work on a model which does not have an associated view. This means we can go the way we sketched offline: The framework needs to provide a way to load documents without an associated view (or to drop the last view without dropping the document at the same time). Then the Spreadsheet SDBC driver can be adjusted to work with the document only, so no hidden frame would be necessary anymore.
Comment 10 Frank Schönheit 2003-01-15 12:34:01 UTC
In agreement with MBA, who's team has to implement the pre-requites for the fix, I change the target to OOo 2.0. It will most probably not be possible to do the required changes in the framework within the 1.1 timeframe.
Comment 11 Mathias_Bauer 2003-01-17 15:00:21 UTC
We will change the way we determine shutdown time in a way that will allow us to ignore documents opened in the "hidden" mode. So documents cached in a drive won't hurt us anymore.
Comment 12 Frank Schönheit 2003-01-17 15:29:40 UTC
for the records: issue 9899 deals with the spreadsheet driver holding a hidden document, too. In one of the proposed solutions of issue 9899, this bug here would vanish, as a Calc connection would only load/lock the document as long as there are open views (tables/queries) to it.
Comment 13 fkater 2003-09-03 13:47:48 UTC
Created attachment 8979 [details] spread sheet with one cell higher than screen size
Comment 14 fkater 2003-09-03 13:49:15 UTC
Sorry! Ignore the attachement please. It's ment for another issue (15632).
Comment 15 Frank Schönheit 2003-10-28 07:09:52 UTC
this is no crash, thus removing dependency to issue 21786
Comment 16 hans_werner67 2004-02-02 12:49:40 UTC
change subcomponent to 'none'
Comment 17 Mathias_Bauer 2004-06-19 17:52:55 UTC
Given that background and the estimated severity I retarget this issue.