|
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)
|