Issue 8174

Summary: soffice/some processes exit delayed after database access
Product: Base Reporter: fkater <f.kater2>
Component: codeAssignee: AOO issues mailing list <issues>
Status: ACCEPTED --- QA Contact:
Severity: Trivial    
Priority: P3 CC: issues
Version: OOo 1.0.1   
Target Milestone: ---   
Hardware: PC   
OS: Linux, all   
Issue Type: DEFECT Latest Confirmation in: ---
Developer Difficulty: ---
Attachments:
Description Flags
spread sheet with one cell higher than screen size none

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.
Comment 18 Marcus 2017-05-20 10:47:35 UTC
Reset assigne to the default "issues@openoffice.apache.org".