The last few days, I’m spending many hours at work trying to migrate our applications from CFMX 6.1 to CF8. For the most part, there are no significant problems. The testing took more time than the few adaptations I had to make to our own code, mainly things like hard-coded paths, server names, etc. So, it was a piece of cake, right? No, it wasn’t.
Why not? Well, I also have to migrate a series of 50+ intranet sites managed by an in-house content management system (CMS), including a search based on the Verity search engine included in ColdFusion. I had everything working in a limited testing environment, but when I recreated the Verity indexes for all those sites things went wrong: creating all the indexes was somewhat doable, but I haven’t been able to reindex all sites in a single swoop. And unfortunately there are no clear error messages, let alone explications for what is going on. I have been able to establish that for some reason the “ColdFusion8 Search Server” stops responding, but I have no explanation for that phenomenon.
Dan Switzer apparently had a similar problem, described on his blog (blog.pengoworks.com/index.cfm/2009/11/6/ColdFusion-8-Search-Server-service-Verity-reporting-Error-1067-on-startup
).
I don’t have the exact same error, but nevertheless a reinstallation of Verity gets me going again… for a while. Dan writes: “I had to re-create all my collection (sic), but that wasn’t a big deal (time consuming, but painless.)”. I have written a script to recreate all our collections, because we have more than 190 of them and I had no intention to redo them all by hand.
Here’s the core of that script: it creates a list of max. 6 collection names and passes that to this function (I’ve simplified the code somewhat to make it more readable and focus on the essence):
<cffunction name="createCollections" output="no" returntype="boolean" > <cfargument name="collections" type="string" required="yes" /> <cfset var status = false /> <cflock name="verityData" timeout="600"> <cfif ( Trim( ARGUMENTS.collections ) NEQ "" ) > <cfset status = true /> <cfloop list="#ARGUMENTS.collections#" index="c" > <cftry> <cfcollection action="CREATE" collection="#c#" path="..." language="..." /> <cfset status = status AND true /> <cfcatch type="any"> <cfset status = false /> </cfcatch> </cftry> </cfloop> </cfif> </cflock> <cfreturn status /> </cffunction>
So far, so good – if it weren’t for the fact that most of the time the script starts to report errors… Checking the situation on the server reveals the fact that somehow the “ColdFusion 8 Search Service” is still running but no longer responding to requests, neither from the CF Administrator nor from my scripts. I’ve been looking all over for clues, but since I am a newbie to Verity I’m not even sure where to look for whatever could be useful. I have found a “diag.log” file (and a corresponding dump file) saying that “Process k2admin (pid 4712) crashed with exception 0xc0000005”. This indicates some kind of illegal memory access – in the C or C++ code for Verity… but that isn’t all too helpful.
I have read in multiple blogs/articles that it pays to add explicit exclusive locking to all operations with the indexes, and I’m checking all our code (I haven’t written any of it, so I’m discovering a while going on) and adding CFLOCKs where appropriate… But will that suffice? Does anyone have any clues as to the nature of this problem and its solution?
In the meantime – and after many experiments – I can offer a few Dos and Dont’s:
- Do not copy existing indexes from CFMX6.1 to CF8 – this simple solution doesn’t seem to work, at least in our case.
- Copying existing indexes into a newly recreated collections directory is not guaranteed to work either…
- Adding CFLOCK’s seems like a very good idea…
- … but isn’t always as simple as it seems, so beware: be consistent and complete in the way you organise these CFLOCK’s
- Updating your specific indexes from within the ColdFusion Administrator will seem to work, but may not return the same results (you can specify more parameters when indexing from code than from within the administration console)
Feel free to add to (or correct!) my findings about this matter!