MissingMethodException from Lucene, need to disable back office search?
Hi,
On my installation where I am using UmbracoExamine RTM documents are slow to publish. On closer inspection of the umbracoLog there are a lot of messages like this:
Error indexing node: System.MissingMethodException: Method not found: 'Void Lucene.Net.Documents.Document.Add(Lucene.Net.Documents.Field)'. at umbraco.cms.businesslogic.index.Indexer.IndexNode(Guid ObjectType, Int32 Id, String Text, String UserName, DateTime CreateDate, Hashtable Fields, Boolean Optimize) at umbraco.cms.businesslogic.web.Document.Index(Boolean Optimze)
This looks to me like the standard back office search trying to index documents but failing because the version of Lucene has changed when I installed Examine.
Is there a way to uninstall or disable the standard back office search?
I've been looking for a solution to this problem for some time, and your reply finally seems to shed some light. So effectively your saying the method that Umbraco or Examine is trying to call in Lucene v2.0.0.4 no longer exists in v2.9.2. The namespace in our errors is umbraco.cms.businesslogic.index.indexer.Indexnode so i'm making the assumption its a standard Umbraco library trying to call this method, rather than Examine.
What's more important to learn is, will this cause any functional issues in the use of Examine & Lucene in Umbraco 4.0.x? We've been using Examine RC3 in our Umbraco 4.0.x build for some time now and we do find indexes need rebuilding fairly regularly. Things like corruption, duplication and index files not getting processed and staying forever in the Queue. Do you know if these issues exist in with Examine in Umbraco 4.5.x?
Again in my attempt to try and get to the bottom of this error you may well say it's completely unrelated to the use of Examine, but a heads up from someone who knows would be good!
Examine/Lucene on the surface seems like a godsend in Umbraco, but in practice we feel its not overly robust at the moment. I've tried to move from RC3 to the RTM, but our Agency has written a bunch of extension dlls around Examine which make calls to methods in much older Examine libraries. We are trying to get the source code for these so we can reference the RTM instead.
I feel an upgrade to 4.5.x will be inevitable to smooth out our bumps in Examine.
Upgrading to 4.5 is highly recommended, not just for Examine but for overall Umbraco performance improvements :P.
Provided you added all the assemblies from the Examine package (including Lucene.Net) Examine will run fun but the backoffice search will not work. Examine will not work at all if you're using Lucene.Net 2.0.0.4.
Yea, I kinda figured an upgrade to v4.5 will be inevitable.
I've tried upgrading to the RTM by simply replacing the dlls and removing the obsolete ones, and yes the backend search doesnt work so I dropped back in a few of the dependent "old" dlls and I did manage to get it working again, unfortunately I have no idea what effect that would have on the newer examine dlls.
I'm monitoring it closely until we can come to an upgrade decision.
MissingMethodException from Lucene, need to disable back office search?
Hi,
On my installation where I am using UmbracoExamine RTM documents are slow to publish. On closer inspection of the umbracoLog there are a lot of messages like this:
This looks to me like the standard back office search trying to index documents but failing because the version of Lucene has changed when I installed Examine.
Is there a way to uninstall or disable the standard back office search?
I would edit this to say it is umbraco 4.0.4.2 but I can't gives me an error when I try to save the edit.
If you're using Examine with 4.0 it will throw that error since Examine uses Lucene.Net 2.9.2 where as 4.0 of Umbraco shipped with Lucene.Net 2.0.0.4.
And there isn't a way to disable the back office search in 4.0
Hi Slace
I've been looking for a solution to this problem for some time, and your reply finally seems to shed some light. So effectively your saying the method that Umbraco or Examine is trying to call in Lucene v2.0.0.4 no longer exists in v2.9.2. The namespace in our errors is umbraco.cms.businesslogic.index.indexer.Indexnode so i'm making the assumption its a standard Umbraco library trying to call this method, rather than Examine.
What's more important to learn is, will this cause any functional issues in the use of Examine & Lucene in Umbraco 4.0.x? We've been using Examine RC3 in our Umbraco 4.0.x build for some time now and we do find indexes need rebuilding fairly regularly. Things like corruption, duplication and index files not getting processed and staying forever in the Queue. Do you know if these issues exist in with Examine in Umbraco 4.5.x?
Again in my attempt to try and get to the bottom of this error you may well say it's completely unrelated to the use of Examine, but a heads up from someone who knows would be good!
Examine/Lucene on the surface seems like a godsend in Umbraco, but in practice we feel its not overly robust at the moment. I've tried to move from RC3 to the RTM, but our Agency has written a bunch of extension dlls around Examine which make calls to methods in much older Examine libraries. We are trying to get the source code for these so we can reference the RTM instead.
I feel an upgrade to 4.5.x will be inevitable to smooth out our bumps in Examine.
Martin
Upgrading to 4.5 is highly recommended, not just for Examine but for overall Umbraco performance improvements :P.
Provided you added all the assemblies from the Examine package (including Lucene.Net) Examine will run fun but the backoffice search will not work. Examine will not work at all if you're using Lucene.Net 2.0.0.4.
Hi Slace
Yea, I kinda figured an upgrade to v4.5 will be inevitable.
I've tried upgrading to the RTM by simply replacing the dlls and removing the obsolete ones, and yes the backend search doesnt work so I dropped back in a few of the dependent "old" dlls and I did manage to get it working again, unfortunately I have no idea what effect that would have on the newer examine dlls.
I'm monitoring it closely until we can come to an upgrade decision.
Thanks for the response.
Martin
is working on a reply...