[MGNLEESOLR-186] Editing decorated module configuration causes module to start with undecorated configuration Created: 21/Mar/23  Updated: 12/Feb/24

Status: Discovery
Project: Solr Search Provider
Component/s: None
Affects Version/s: 6.1.2
Fix Version/s: None

Type: Bug Priority: Neutral
Reporter: Viet Nguyen Assignee: Dai Ha
Resolution: Unresolved Votes: 2
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Relates
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)
Bug DoR:
[ ]* Steps to reproduce, expected, and actual results filled
[ ]* Affected version filled
Epic Link: Support
Team: DeveloperX
Work Started:

 Description   

Steps to reproduce

  1. Deploy indexing configuration via decorations mechanism, and Java module contains src/main/resources/hsf-people-indexer/decorations/content-indexer/config.indexers.peopleIndexer.yaml decorator - it adds an indexer configuration.
  2. When we run full re-indexing we set /modules/content-indexer/config/indexers/peopleIndexer@indexed property to false.
  3. This triggers set of events that is causing problem:
  • ModuleJcrConfigurationSource recieves "property modified" JCR events
  • ModuleJcrConfigurationSource.reload(List<Node>) executes getRegistry().register(newProvider(node)) for the configuration nodes.
  • newProvider(Node) causes module to stop and again start using undecorated module definitions. This fails with exception (stacktrace below) because JCR does not contain complete Indexer Configuration.
  • register(DefinitionProvider<T>) causes module to stop and start again, this time with correctly decorated definition.

.. Logs, screenshots, gifs...

Expected results

  • Module should be restarted once and using its decorated information.

.. Justify non-trivial expectations with a link to a doc or a relevant discussion.

Actual results

  1. Our concern here is that this bug triggers reindexing with incorrect configuration which have potential to corrupt data in Solr index.
java.lang.NullPointerException: null
	at java.util.Hashtable.get(Hashtable.java:380) ~[?:?]
	at info.magnolia.repository.WorkspaceMapping.getWorkspaceMapping(WorkspaceMapping.java:124) ~[magnolia-core-6.2.28.jar:?]
	at info.magnolia.repository.DefaultRepositoryManager.getSystemSession(DefaultRepositoryManager.java:322) ~[magnolia-core-6.2.28.jar:?]
	at info.magnolia.context.SystemRepositoryStrategy.internalGetSession(SystemRepositoryStrategy.java:71) ~[magnolia-core-6.2.28.jar:?]
	at info.magnolia.context.AbstractRepositoryStrategy.getSession(AbstractRepositoryStrategy.java:75) ~[magnolia-core-6.2.28.jar:?]
	at info.magnolia.context.AbstractContext.getJCRSession(AbstractContext.java:124) ~[magnolia-core-6.2.28.jar:?]
	at info.magnolia.module.indexer.DataIndexer.init(DataIndexer.java:72) ~[magnolia-content-indexer-6.1.2.jar:?]
	at info.magnolia.module.indexer.DataIndexerFactory.init(DataIndexerFactory.java:75) ~[magnolia-content-indexer-6.1.2.jar:?]
	at info.magnolia.module.indexer.ContentIndexerModule.start(ContentIndexerModule.java:77) ~[magnolia-content-indexer-6.1.2.jar:?]
	at info.magnolia.module.ModuleManagerImpl.startModule(ModuleManagerImpl.java:386) ~[magnolia-core-6.2.28.jar:?]
	at info.magnolia.module.ModuleManagerImpl.lambda$startModules$0(ModuleManagerImpl.java:353) ~[magnolia-core-6.2.28.jar:?]
	at info.magnolia.module.StartModuleEvent.dispatch(StartModuleEvent.java:52) ~[magnolia-core-6.2.28.jar:?]
	at info.magnolia.module.StartModuleEvent.dispatch(StartModuleEvent.java:42) ~[magnolia-core-6.2.28.jar:?]
	at info.magnolia.event.SimpleEventBus.fireEvent(SimpleEventBus.java:75) ~[magnolia-core-6.2.28.jar:?]
	at info.magnolia.config.module.ModuleMap2BeanTransformer.lambda$transform$1(ModuleMap2BeanTransformer.java:101) ~[magnolia-configuration-6.2.28.jar:?]
	at info.magnolia.context.MgnlContext.doInSystemContext(MgnlContext.java:378) ~[magnolia-core-6.2.28.jar:?]
	at info.magnolia.context.MgnlContext.doInSystemContext(MgnlContext.java:356) ~[magnolia-core-6.2.28.jar:?]
	at info.magnolia.config.module.ModuleMap2BeanTransformer.transform(ModuleMap2BeanTransformer.java:97) ~[magnolia-configuration-6.2.28.jar:?]
	at info.magnolia.config.source.jcr.JcrConfigurationSource.newProvider(JcrConfigurationSource.java:200) ~[magnolia-configuration-6.2.28.jar:?]
	at info.magnolia.config.module.ModuleJcrConfigurationSource.reload(ModuleJcrConfigurationSource.java:120) ~[magnolia-configuration-6.2.28.jar:?]
	at info.magnolia.config.module.ModuleJcrConfigurationSource.reload(ModuleJcrConfigurationSource.java:106) ~[magnolia-configuration-6.2.28.jar:?]
	at info.magnolia.observation.DeferringEventListener$ObservationBasedDelayedExecutor$1.run(DeferringEventListener.java:102) ~[magnolia-core-6.2.28.jar:?]
	at info.magnolia.cms.util.DelayedExecutor$RunnableWrapper.run(DelayedExecutor.java:103) ~[magnolia-core-6.2.28.jar:?]
	at EDU.oswego.cs.dl.util.concurrent.ClockDaemon$RunLoop.run(Unknown Source) ~[concurrent-1.3.4.jar:?]
	at java.lang.Thread.run(Thread.java:834) ~[?:?]

Workaround

  • N/A

Development notes

  • The observation on module's configuration changed triggered the restart which uses wrong configuration (without decoration).
  • Also let's consider how to make it trigger only 1 restart as double it give no benefit in this case.

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