Bug 661738 - Very slow java database operations: Attach/DetachCurrentThread
Summary: Very slow java database operations: Attach/DetachCurrentThread
Alias: None
Product: Fedora
Classification: Fedora
Component: openoffice.org
Version: 14
Hardware: i686
OS: Linux
Target Milestone: ---
Assignee: Stephan Bergmann
QA Contact: Fedora Extras Quality Assurance
Depends On:
TreeView+ depends on / blocked
Reported: 2010-12-09 14:51 UTC by Perazim
Modified: 2019-09-18 13:39 UTC (History)
5 users (show)

Fixed In Version: libreoffice-
Doc Type: Bug Fix
Doc Text:
Clone Of:
Last Closed: 2012-01-30 20:57:36 UTC
Type: ---

Attachments (Terms of Use)
simple database with one table with 500 records (26.37 KB, application/vnd.oasis.opendocument.database)
2010-12-09 14:51 UTC, Perazim
no flags Details

System ID Private Priority Status Summary Last Updated
FreeDesktop.org 35023 0 None None None Never
Launchpad 724217 0 None None None Never
Sun Bug Database 6929067 0 None None None Never
Sun Bug Database 7024514 0 None None None Never

Description Perazim 2010-12-09 14:51:32 UTC
Created attachment 467759 [details]
simple database with one table with 500 records

Description of problem:Very slow database operations

Version-Release number of selected component (if applicable):openoffice.org-base-3.3.0-17.2.fc14.i686  (OOO330m17)

How reproducible:every time

Steps to Reproduce:open a database table, seek to end, notice time used
Actual results:

Expected results:

Additional info: When I open a database file from f-12 system which I think is OOO320, it runs VERY slow. It takes nearly 60 seconds to access record 121 (the end) of a small table. Other operations, like mail merge exhibit slowness too. CPU usage during this time is 100%.

32 bit version f-14 running on Acer Travelmate 7320 with 2GB RAM. Reasonably
fast processor.

Tried copying to new table in same database - same performance.

Tried copying to new table in new database - same performance.

Tried exporting to spreadsheet and then re-importing - same performance.

Tried creating simple spreadsheet 18 columns x 500 rows. First cell has
ascending integer. Then imported to database table with a primary key. 
Time to open first page of 33 records: 12 seconds.

Time to seek to last record using "end" button: 48 seconds.

I have attached this test database file.

I have previously reported this to openoffice.org. They have not been able to reproduce it and have instructed me to report it here.

Comment 1 Caolan McNamara 2012-01-10 13:45:16 UTC
caolanm->sbergman: can you see if this still seems to affect current fedora or if it was fixed by the context-foo I seem to recall you mentioning in relation to java stuff. 

And/or if we know its java's fault throw it over the wall to that team to have a look at

Comment 2 Stephan Bergmann 2012-01-10 14:15:01 UTC
This is known upstream as <https://bugs.freedesktop.org/show_bug.cgi?id=35023> "FILEOPEN Base functions extremely slowly with Java 1.6.0_20 and >1.6.0_24."  (For details, see esp. the 12th comment there and the referenced mail thread at <http://nabble.documentfoundation.org/Trying-to-diagnose-base-running-extremely-slowly-tt3426499.html#a3436909>.)

It is an unfortunate combination of JNI Attach/DetachCurrentThread having become significantly more expensive in recent Java versions and the LO Base code calling those JNI functions very frequently.

Comment 3 Caolan McNamara 2012-01-10 14:52:19 UTC
caolanm->sbergmann: do you know if its base that's calling Attach/DetachCurrentThread a lot or if its hsqldb itself ?

Comment 4 Caolan McNamara 2012-01-10 14:59:44 UTC
http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6929067 seems to trigger http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7024514 which is basically this bug. Any cunning ideas ?

Comment 5 Deepak Bhole 2012-01-10 15:42:09 UTC
The fix for http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6929067 introduced another issue:

So we basically need to backport these 2:

Andrew, do you see any issues with backporting the above (you reviewed the latter)? If not, I can propose a backport to the hotspot list.

Comment 6 Andrew Haley 2012-01-10 15:55:41 UTC
These fixes won't necessarily fix the real problem. If someone can come up with an actual reproducible test case I'll have a look. But it has to be better than "Just create a SQL table with more than 100 rows", it has to be something I can do.

Comment 7 Stephan Bergmann 2012-01-10 17:02:53 UTC
reproducible test case:  with libreoffice-base package installed, call soffice with the attached New Database1.odb, select "Tables" in the left pane, double-click "Table 1" in the lower right pane, new window opens, click the little "go to end" button at the bottom of the window (left of the horizontal scroll bar, there are buttons with "go to beginning," "previous," "next," "go to end" icons): takes multiple seconds

Comment 8 Andrew Haley 2012-01-10 18:44:23 UTC
The problem is here:

void SAL_CALL java_sql_PreparedStatement::setInt( sal_Int32 parameterIndex, sal_Int32 x ) throw(::com::sun::star::sdbc::SQLException, ::com::sun::star::uno::RuntimeException)
    m_aLogger.log( LogLevel::FINER, STR_LOG_INT_PARAMETER, parameterIndex, x );
    ::osl::MutexGuard aGuard( m_aMutex );

    SDBThreadAttach t; OSL_ENSURE(t.pEnv,"Java Enviroment geloescht worden!");

^^^ Note that for every setInt, the thread is attached and then
detached.  This makes no sense at all.  You need a parameter that
keeps track of whether a thread is attached or not.  Either that, or
dedicate a separate thread to the Java database access.  There is
nothing much that can be done to make jni_{Attach,Detach}CurrentThread
super-fast; it needs to be used less often.
    static jmethodID mID(NULL);
    callVoidMethod("setInt", "(II)V", mID, parameterIndex, x);

Comment 9 Stephan Bergmann 2012-01-10 19:28:14 UTC
Thanks Andrew for confirming that the LO code needs fixing.  The original developer always claimed this was hard to do.  Will have to have a look into this.

Comment 10 Andrew Haley 2012-01-11 11:47:21 UTC
There is an alternative: attach the thread and leave it attached.  You'll have to make sure that the Java stack limit is large enough to accommodate the maximum extent to which the stack may ever grow.

Comment 11 Stephan Bergmann 2012-01-13 10:55:21 UTC
will be fixed in >=libreoffice- (backporting fix for upstream <https://bugs.freedesktop.org/show_bug.cgi?id=35023> "FILEOPEN Base functions extremely slowly with Java 1.6.0_20 and >1.6.0_24")

Comment 12 Fedora Update System 2012-01-25 08:45:00 UTC
libreoffice- has been submitted as an update for Fedora 16.

Comment 13 Fedora Update System 2012-01-25 22:27:24 UTC
Package libreoffice-
* should fix your issue,
* was pushed to the Fedora 16 testing repository,
* should be available at your local mirror within two days.
Update it with:
# su -c 'yum update --enablerepo=updates-testing libreoffice-'
as soon as you are able to.
Please go to the following url:
then log in and leave karma (feedback).

Comment 14 Fedora Update System 2012-01-30 20:57:36 UTC
libreoffice- has been pushed to the Fedora 16 stable repository.  If problems still persist, please make note of it in this bug report.

Note You need to log in before you can comment on or make changes to this bug.