[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: |
|
||||||||||||||||||||||||||||
| 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 ] |
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:
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 is blocked for 3:34 by an asynchronous task running in Quartz, running: 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). |