serverInfo returns error on Alfresco Enterprise 4.2.3 (/alfresco/s/de/fme/jsconsole/serverInfo)
Closed this issue · 8 comments
The error is:
message": "00150315 Wrapped Exception (with status template): 00150626 Failed to execute script 'classpath_:alfresco/extension/templates/webscripts/de/fme/jsconsole/serverInfo.get.js': No bean named 'search.solrIndexCheckService' is defined",
"exception": "org.springframework.extensions.webscripts.WebScriptException - 00150315 Wrapped Exception (with status template): 00150626 Failed to execute script 'classpath_:alfresco/extension/templates/webscripts/de/fme/jsconsole/serverInfo.get.js': No bean named 'search.solrIndexCheckService' is defined",
Searching for that error, I see that this bean didn't exist in Alfresco Community ever, and was renamed or removed in Alfresco Enterprise 4.2: jgoldhammer/alfresco-jscript-extensions#6
I believe this is the same issue as in #21 - serverInfo.get.js unfortunately requires that SOLR is used as the search subsystem to display / calculate the output. In my opinion, the serverInfo.get web script should be removed as its output is rarely useful.
I don't think so. The error looks different, and the server has Solr set up and is the search service the system is using)
Hmm, ok - maybe I was a bit quite on the assumption there. It's definitely a Community-only issue, because the bean still exists in Enterprise 4.2(.3) and 5.0 without change in name.
But the basic issue / fault is the same as in #21 - the serverInfo.get.js SHOULD NOT rely on SOLR (or any other optional subsystem) to be available. And it shouldn't use a JavaScript-access-to-Spring hack to get beans that "may" not be available...
I'm seeing this issue on Alfresco Enterprise 4.2.3 using Solr as the search service. But I agree that recovering from failures would help.
@AFaust you are right, Axel. There must be a redesign- any ideas? A java backed webscript should be better here...
For now, I will disable SOLR in the serverInfo.get.js.
And no, I will not completely remove the script because it can provide some useful info...
Thanks,
Jens
I have never seen useful info, but as long as it does not throw a tantrum because of SOLR being unavailable, I don't care if it's there or not.
The problem with re-design is that you'd need to decide on the lowest supported Alfresco version for the re-design. E.g. the query could be performed in Java-backed web script using transactional metadata queries, but this forces Alfresco 4.2 as lowest version and also forces users to apply the optional metadata indices on the database or it would not return any info for a subset of users.
@jgoldhammer Recently found another issue with serverInfo.get.js when a customer used JavaScript Console. Customer had 25+ million nodes in the repository and is still using Lucene (on 4.2.4) - load of JavaScript Console for administration purposes triggered serverInfo.get.js and its "search for up to 1.000.000 content / folder / checked-out nodes". This effectively cleared out all the internal node caches since this is guaranteed to load more "new nodes" into transactional cache than the transactional cache can handle and thus clear the shared cache upon commit (see JavaDoc of TransactionalCache).
Looking at the current state of master, moving serverInfo.get.js call into its own tab and require admin to trigger it explicitly fixes my major complaints. Maybe there should be some additional warning applied to it (e.g. "may clear out important caches")..
If the original issue of @xkahn no longer occurs, this issue may be ready to be closed...
I will close the issue now because the problem seems to be resolved