[MGNLUI-3972] Avoid excessive access to the version store while browsing content Created: 05/Aug/16  Updated: 09/Feb/17  Resolved: 08/Oct/16

Status: Closed
Project: Magnolia UI
Component/s: content app
Affects Version/s: None
Fix Version/s: 5.5

Type: Improvement Priority: Major
Reporter: Philipp Bärfuss Assignee: Jaroslav Simak
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Cloners
is cloned by MAGNOLIA-6776 Implement mixin mgnl:hasVersion to av... Closed
is cloned by MGNLUI-4020 Excessive access to the version store... Closed
Relates
dependency
depends upon MAGNOLIA-6776 Implement mixin mgnl:hasVersion to av... Closed
relation
Template:
Acceptance criteria:
Empty
Task DoD:
[ ]* Doc/release notes changes? Comment present?
[ ]* Downstream builds green?
[ ]* Solution information and context easily available?
[ ]* Tests
[ ]* FixVersion filled and not yet released
[ ]  Architecture Decision Record (ADR)
Date of First Response:
Sprint: Kromeriz 65
Story Points: 2

 Description   

Each click on an elements in content apps leads to requests to the version store. This can be expensive especially for big installations. I have not tracked it down but my guess would be that it is a availability test for an action which checks wether the node has versions or not.

To verify this one can enable derby logging like described here: http://magnolia-experts.com/monitoring-queries-to-the-derby-database/

Attention: jackrabbit caches nodes in memory (16MB bei default) so with a small installation like the demo project the queries will be only executed during the first access and not by follow up browsing.



 Comments   
Comment by Jan Haderka [ 11/Aug/16 ]

Solution Approach
Maybe the code should not use the version API but only check for the existence of the corresponding node in the Magnolia version workspace. Whether this would solve the problem or still lead to these queries I don't know

This approach could be considered as workaround, but not as final solution due to possibility of having nodes with same path coming from different workspaces and thus causing false positives.

Comment by Mikaël Geljić [ 11/Aug/16 ]

This may be regarded as a more general issue as well:

  • JCR node adapters read properties lazily upon request, causing a number of repeated JCR operations from various entry points already (e.g. selection, action bar, column formatters).
  • AvailabilityChecker and AvailabilityRules take itemIds as input, meaning that several such rules need to get the JCR item again, upon evaluation.

As I see it, already forwarding the Vaadin Item, as is, for availability checking could help mitigate JCR access; while a revised JCR/Vaadin integration (with adapters aware of Magnolia's custom versioning) should ensure that Items already loaded inside Containers serve as this cache, and do not require further access for regular browsing (ideally even less server roundtrips).

I understand that's further down the road, so maybe in the meantime, we could try to wrap the version info somewhere else, but it's not quite obvious, at least as long as we have so many distinct entry points.

Comment by Andrew Warinner [ 02/Sep/16 ]

We see a lot of contention between different threads competing for BaseVersionManager.

One examples, I have many more:

Tomcat request thread (ajp-bio-8009-exec-20) calling
info.magnolia.cms.core.version.BaseVersionManager.getVersionHistory():312
info.magnolia.ui.framework.availability.HasVersionsRule.isAvailableForItem():71

is blocked for 3:34 by an asynchronous task running in Quartz, running:
info.magnolia.cms.core.version.BaseVersionManager.createVersion():257

BaseVersionManager has a lot of synchronized methods, getVersionHistory in particular, that will lead to contention between the UI and everything else, especially when the instance is heavily loaded or access to the versions table is expensive.

Comment by Mikaël Geljić [ 02/Sep/16 ]

Thanks awarinner for the detailed finding,

So as far as I see, even with best of breed UI patterns to mitigate those accesses, this might only displace the issue (e.g. to opening the app or refreshing the tree).
As far as action availability is concerned, we certainly do not need 100% consistency in that regard, so a way around the synchronized part could do; we can certainly expose different ways from the BaseVersionManager too if it makes sense.

Generated at Mon Feb 12 09:11:59 CET 2024 using Jira 9.4.2#940002-sha1:46d1a51de284217efdcb32434eab47a99af2938b.