[MGNLUI-4545] Investigate polishing of datasource observation mechanism in content apps Created: 15/Jun/18  Updated: 20/Aug/18  Resolved: 17/Jul/18

Status: Closed
Project: Magnolia UI
Component/s: None
Affects Version/s: None
Fix Version/s: 6.0

Type: Task Priority: Neutral
Reporter: Aleksandr Pchelintcev Assignee: Roman Kovařík
Resolution: Done Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Cloners
is cloned by MGNLUI-4566 Polish datasource observation mechani... Closed
dependency
is depended upon by MGNLUI-4531 Polish browsing functionality impleme... Closed
Template:
Acceptance criteria:
Empty
Task DoR:
Empty
Date of First Response:
Epic Link: UI framework implementation
Sprint: Kromeriz 155, Kromeriz 156
Story Points: 5

 Description   

primary goal

  • get away from the inevitable need of content changed events. In the new incarnation of the content app we try to stay away from the ContentChangedEvent since it is an error-prone and cumbersome way to communicate the changes. Instead we try to utilise the native datasource observation capabilities relief the app developer from having to send notifications manually.
  • browser views should not have any imperative logic re: refreshing the views. Instead e.g. the table should use Vaadin DataProvider API and data providers should optionally subscribe to the backend events

possible solution

  • JCR - use the wrapper around observation mechanism
    • do not want to have too many listeners at once. Maybe create a singleton pool of the listeners, which would broadcast the changes to the data providers?
    • non-JCR: depends on the capabilities of the backend
      • there could be no capabilities (like REST)
      • we could provide e.g. smth like localised CCE: specific action injects the specific DS observation and pushes the event
        additional complications
    • we have some relying on the CCE in other places. E.g. details sub-apps catch them and automatically close once it is received.
    • how do we leverage that situation?


 Comments   
Comment by Roman Kovařík [ 13/Jul/18 ]

My questions/concerns raised when investigating (more or less related to the topic)

  • info.magnolia.contentapp.framework.datasource.DatasourceSupport
    • Sources are referenced by definition.
      • How is this support to work with multiple apps for different workspaces?
      • Is this just a mistake and bundles should be referenced by the definition object?
    • DatasourceSupport is a singleton
      • the bundles are kept in memory forever
        • is this intended? 
        • as consequence, registered observations can't be released implicitly
        • for record, the singleton storage looks like this (in case of JCR):
          • DatasourceSupport -> JcrDatasourceBundle -> HierarchicalJcrDataProvider (among other objects, some of these don't hold any data so there is no problem with these) -> JcrObservation
        • What should be the correct scope?
          • Looks like @UiScopedComponent doesn't coop with @Multibinding (which is used by DatasourceBundles)
          • @SessionScoped?
  • Pool of listeners
    • implementation is fairly straitforward
    • since the "delegating" listeners is registered at root level, every subscriber would have to have an inner logic to filter event on its subpath 
    • wouldn't then be easier to register listener on JCR level per app with proper root path so no additional logic would be needed?
      • if the datasource would be app scoped, the listener would/should be unregistered after closing the app
      • although pool of listeners sounds like a good idea, what's the different having the pool at Magnolia UI vs. JCR level?
        • the number of listener shouldn't be enormous (= number of opened apps per user), with the pool, the registration point would just move from JCR to UI. After implementing the pool, I have doubts about benefit of this solution.
  • Investigated solutions for memory leaks
    •  WeakHashMap: 
      • works quite well in a simple use case
      • in our case are the items in the map (multiple wrapped consuments - inner class/lambdas) evicted too early) 
    •  info.magnolia.contentapp.framework.datasource.components.JcrDataSourceObservation#finalize
      • a private field holds an object which is able to unregister a subscription
        • this fields needs to be static otherwise is nullified before the finalise method is called
      • similarly as with WeakHashMap, the finalise method was called too early, but that could a be a problem with my implementation.
  • Summary
    • Some questions regarding the data source observation arised.
    • Implementation if interaction between the data source and view might continue (as the datasource observation works in current state of the content app, even without the PoC with the pool)
Comment by Roman Kovařík [ 13/Jul/18 ]

Added a PR with the observation pool for the record.

Comment by Roman Kovařík [ 16/Jul/18 ]

Explained / Discussed. Closing so we can move on with actual impl (DEV-1027).

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