-
Bug
-
Resolution: Fixed
-
Medium
-
3.5
-
Managed to reproduced with a plugin using both plugins v1 and v2 frameworks.
The Custom Query mappers modules are not getting loaded once the server is restarted.
This is causing a serious problem in Ad hoc Workflows. The workaround is manually reloading the lucene-query-mapper modules.
Recreating the problem:
- When the plugin containing the lucene-query-mapper modules is installed, no problem, everything works
- When the server is restarted, trying to access the query causes an exception like this one:
com.atlassian.confluence.search.v2.lucene.LuceneMapperNotFoundException: A lucene mapper could not be found to map an object of type: com.atlassian.confluence.search.v2.SearchQuery and key: workflowassignee at com.atlassian.confluence.search.v2.lucene.DelegatingLuceneSearchMapper.convertToLuceneQuery(DelegatingLuceneSearchMapper.java:28) at com.atlassian.confluence.search.v2.lucene.mapper.BooleanQueryMapper.addSubQueries(BooleanQueryMapper.java:43) at com.atlassian.confluence.search.v2.lucene.mapper.BooleanQueryMapper.convertToLuceneQuery(BooleanQueryMapper.java:29) at com.atlassian.confluence.search.v2.lucene.DelegatingLuceneSearchMapper.convertToLuceneQuery(DelegatingLuceneSearchMapper.java:30) at com.comalatech.confluence.workflowreports.TwoPointNineWorkflowReportCreator.debugQuery(TwoPointNineWorkflowReportCreator.java:138) at com.comalatech.confluence.workflowreports.TwoPointNineWorkflowReportCreator.makeEntries(TwoPointNineWorkflowReportCreator.java:131) at com.comalatech.confluence.workflowreports.TwoPointNineWorkflowReportCreator.createDashboardReport(TwoPointNineWorkflowReportCreator.java:78)
Please note that this is a confluence issue, which happens to have an effect in Ad hoc Workflows
[CONFSERVER-22014] lucene-query-mapper plugin modules are not getting loaded properly upon server restart
Actually, the problem is that we're getting an event in 3.5 prior to the plugins being up. In 3.4, there was no event published on startup, and the lazy-loading of the query mappers was done when the first search was executed. So the next question is what is this event in 3.5. Investigation continues.
Okay, I've reproduced the problem, although it seems that the latest Ad Hoc Workflow plugin is already working around it by attempting to disable a non-existent plugin. That will fire the necessary plugin event and refresh the cache. Not elegant, but it works.
The code around the event listening and management of the LuceneSearchMapperRegister has not changed in 3.5. There must be a more fundamental change in how the events come out of the plugin system which happened in atlassian-plugins 2.7 or 2.7.1. The problem seems to be that the mapper registry cache is refreshed when the plugin system begins to start up, rather than when it is finished starting. This means the cache at start-up only has the core mappers registered, and not any of the ones which are loaded from other plugin loaders (bundled or database).
I can't see anything in the PLUG changelog related to events in 2.7 or 2.7.1, so this needs further investigation and probably a chat with Don. I suspect the semantics of some of the plugin events have been changed in this release, in a way that potentially breaks backwards compatibility in a few areas in Confluence.
Update: clarify what I've seen of the problem.
Guy Fraser [Adaptavist.com]
added a comment - Several Adaptavist plugins are also being affected by this issue. We're getting more and more reports in our public forums from customers who have been affected by this, so this issue is causing widespread pain.
Guy Fraser [Adaptavist.com]
added a comment - Several Adaptavist plugins are also being affected by this issue. We're getting more and more reports in our public forums from customers who have been affected by this, so this issue is causing widespread pain. I have attached a workaround which is implemented as a component. It resets the cache when the plugin is installed so it will be re-built the first search is run.
It is not a good solution and shouldn't be considered a "fix" for the bug.
We are seeing exactly the same problem. As far as I can see the problem is due to the CacheBackedLuceneSearchMapperRegistry and LuceneSearchMapperRegistryCacheUpdateListener. LuceneSearchMapperRegistryCacheUpdateListener is supposed to ensure that the cache is refreshed when a plugin event occurs. It is not seeing the event on startup.
Using a debugger it looks as if the only plugin event seen by LuceneSearchMapperRegistryCacheUpdateListener during startup is when the new code macro is started, that populates the cache and then my plugin gets started, but no event is generated for that.
Roberto, there was a Lucene upgrade included in Confluence 3.5. Perhaps that has caused some incompatibility?
I haven't yet had time to try to reproduce this. Are there any errors further up in the log file which indicates why the plugin modules aren't being enabled at start-up?
Turns out this is the new code macro, which has some odd code to try to enable/disable itself depending on the state of the old one.
I'll look into whether we can remove this. Seems like it's unnecessary now – we can just permanently remove the old one.
The event handling in the cache should also be made more robust. These kind of changes shouldn't break the cache.