Bug 113671 - CMS History tab is very slow with a large number of versions
CMS History tab is very slow with a large number of versions
Status: CLOSED WONTFIX
Product: Red Hat Enterprise CMS
Classification: Retired
Component: ui (Show other bugs)
5.2
All Linux
medium Severity medium
: ---
: ---
Assigned To: ccm-bugs-list
Jon Orris
:
Depends On:
Blocks: 108451
  Show dependency treegraph
 
Reported: 2004-01-16 06:57 EST by Matthew Booth
Modified: 2007-04-18 13:01 EDT (History)
1 user (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2005-09-29 10:40:44 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Matthew Booth 2004-01-16 06:57:39 EST
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.5)
Gecko/20031026 Firebird/0.7

Description of problem:
Camden has a page on their intranet which they modify regularly.
Consequently it has about 160 versions. The history tab of the item
admin ui for this page takes several minutes to load.

This is partly because their Oracle DB is hosed and a site node lookup
takes over a second, however it is greatly compounded by the fact that
this exact same query, exact same bind variables, along with several
others which run perfectly quickly, is executed once for every
displayed version.

Although I haven't tested it myself, I'm assured that this will still
be a problem in rickshaw.

Version-Release number of selected component (if applicable):


How reproducible:
Always

Steps to Reproduce:
1. Create an item
2. Create hundreds of versions of it
3. Go to the History tab in the item admin ui.
    

Additional info:
Comment 1 Richard Li 2004-01-16 07:06:24 EST
>this exact same query, exact same bind variables, along with several
>others which run perfectly quickly, is executed once for every
>displayed version.

can you paste the query trace/plan from ds?

>Although I haven't tested it myself, I'm assured that this will still
>be a problem in rickshaw.

Can you clarify? The entire versioning system was rewritten after 5.2.
Comment 2 Matthew Booth 2004-01-16 10:21:31 EST
As requested. Note that the query is executed by the multiple
execution of
com.arsdigita.cms.ui.history.ItemHistoryTable$PreviewCellRenderer.getComponent(),
so it's a UI thing, not a persistence thing. This is why we think
it'll still be there in Rickshaw.

Execution time included for amusement value :) This DB is hosed.

# Execution Time: 1043 ms
# Connection ID: 4847195
# Type: execute
# Query:

select *
from (select apm_packages.package_id as package_id,
             mountPoint__acs_objects.default_domain_class as
nt__acs_objcts__dflt_dmn_clss,
             mountPoint__acs_objects.display_name as
mntPnt__acs_objcts__dsply_nm,
             mountPoint__acs_objects.object_id as
mntPnt__acs_objcts__objct_id,
             mountPoint__acs_objects.object_type as
mntPnt__acs_objcts__objct_typ,
             mountPoint__site_nodes.directory_p as
mntPnt__st_nds__drctry_p,
             mountPoint__site_nodes.name as mountPoint__site_nodes__name,
             mountPoint__site_nodes.parent_id as
mntPnt_prnt__st_nds__prnt_id,
             mountPoint__site_nodes.pattern_p as mntPnt__st_nds__pttrn_p,
             mountPoint__site_nodes.url as mountPoint__site_nodes__url
      from acs_objects mountPoint__acs_objects,
           apm_packages apm_packages,
           site_nodes mountPoint__site_nodes
      where apm_packages.package_id=mountPoint__site_nodes.object_id
      and mountPoint__site_nodes.node_id=mountPoint__acs_objects.object_id
      and apm_packages.package_id=?) results
order by mntPnt__acs_objcts__objct_id

# Bindvars: {1=583}
# Query Execution Plan
# Exception: null
# StackTrace:

	at
com.arsdigita.db.PreparedStatement.logQuery(PreparedStatement.java:123)
	at
com.arsdigita.db.PreparedStatement.doExecute(PreparedStatement.java:215)
	at com.arsdigita.db.PreparedStatement.execute(PreparedStatement.java:189)
	at com.arsdigita.persistence.DataStore.fireOperation(DataStore.java:333)
	at com.arsdigita.persistence.DataStore.fireOperation(DataStore.java:168)
	at
com.arsdigita.persistence.DataQueryImpl.executeQuery(DataQueryImpl.java:1048)
	at
com.arsdigita.persistence.DataAssociationCursorImpl.executeQuery(DataAssociationCursorImpl.java:135)
	at
com.arsdigita.persistence.DataQueryImpl.checkResultSet(DataQueryImpl.java:1024)
	at com.arsdigita.persistence.DataQueryImpl.next(DataQueryImpl.java:479)
	at
com.arsdigita.kernel.PackageInstance.getDefaultMountPoint(PackageInstance.java:154)
	at com.arsdigita.cms.ContentSection.getSiteNode(ContentSection.java:270)
	at com.arsdigita.cms.ContentSection.getPath(ContentSection.java:301)
	at
com.arsdigita.cms.dispatcher.SimpleItemResolver.generatePreviewURL(SimpleItemResolver.java:334)
	at
com.arsdigita.cms.dispatcher.SimpleItemResolver.generateItemURL(SimpleItemResolver.java:435)
	at
com.arsdigita.cms.dispatcher.SimpleItemResolver.generateItemURL(SimpleItemResolver.java:413)
	at
com.arsdigita.cms.ui.history.ItemHistoryTable$PreviewCellRenderer.getComponent(ItemHistoryTable.java:236)
	at com.arsdigita.bebop.Table.generateXML(Table.java:731)
	at
com.arsdigita.bebop.SimpleContainer.generateXML(SimpleContainer.java:243)
	at com.arsdigita.bebop.TabbedPane.generateXML(TabbedPane.java:444)
	at
com.arsdigita.bebop.SimpleContainer.generateXML(SimpleContainer.java:243)
	at com.arsdigita.bebop.Page.generateXML(Page.java:640)
	at com.arsdigita.bebop.Page.buildDocument(Page.java:738)
	at com.arsdigita.cms.dispatcher.CMSPage$1.excurse(CMSPage.java:223)
	at com.arsdigita.cms.CMSExcursion.run(CMSExcursion.java:72)
	at com.arsdigita.cms.dispatcher.CMSPage.dispatch(CMSPage.java:229)
	at
_packages._content_22dsection._www._admin._item__jsp._jspService(_item__jsp.java:59)
Comment 3 Richard Li 2004-01-16 10:27:08 EST
The com.arsdigita.cms.ui.history package doesn't exist in Rickshaw or
Troika.
Comment 4 Vadim Nasardinov 2004-01-16 10:29:30 EST
I was the one who deleted it, but it was Justin (and possibly Rafi) who
had worked on the UI that replaced this.

$ p4 describe -s 32431
Change 32431 by vadim@el-vadimo on 2003/06/16 12:08:48

	Changed the visibility of three classes from public to package-scoped.
	ItemHistoryTable was using one of these classes for debugging.  Justin
	said I could delete the entire
	//cms/dev/src/com/arsdigita/cms/ui/history/... directory, and so I did.

Affected files ...

... //cms/dev/src/com/arsdigita/cms/ui/history/ItemHistory.java#7 delete
... //cms/dev/src/com/arsdigita/cms/ui/history/ItemHistoryTable.java#15 delete
... //cms/dev/src/com/arsdigita/cms/ui/history/package.html#3 delete
... //core-platform/dev/src/com/arsdigita/versioning/DevSupport.java#3 edit
... //core-platform/dev/src/com/arsdigita/versioning/RollbackAdapter.java#2 edit
... //core-platform/dev/src/com/arsdigita/versioning/RollbackListener.java#2 edit
Comment 5 Matthew Booth 2004-01-16 10:31:00 EST
Couple of possibilities there:

1. It got refactored and the same bug now exists elsewhere.
2. I'm wrong :)

Either way, it's definitely a problem in 5.2
Comment 6 Richard Li 2004-01-16 10:34:01 EST
based on above, targeting for 5.2.3 only, not 6.x errata stream
until/unless we get definitive data on 6.x

add bche to cc:; if we have time we'll see about reproducing on rickshaw
Comment 7 Daniel Berrange 2004-01-16 10:40:23 EST
FYI, the (new in 6.0) com.arsdigita.cms.ui.revision package contains
the class ItemRevisionAdminPane which creates a table containing one
row per revision. The cell renderer for this calls the same URL
generation code as the old 5.2 UI. 

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