Copy link to clipboard
Copied
I work in a CF shop running enterprise 8.01 HF3. We have a server farm of quad core processors with more than enough memory, and in the past would pay for Adobe support. There were many problems with Adobe Support.
a) It's nearly impossible to prove to Level1 that you know more than they do, and you require an escalation.
b) The folks that handle escalations rarely know more about CF than a veteran developer
c) Nobody knows anything about Verity.
Naturally, we stopped paying for the unservice of Adobe Support (simliar to an "unvitation", ala Seinfield), so the forums are my only outlet.
This is a history of my adventure trying to fix Verity...and losing.
It all began on a rainy evening in 2008. The lights were dim, the music was blaring, and we were upgrading from CF6 to CF8. It was a beautiful time. Things were great at first, but that courtship didn't last long. Immediately we experienced issues with the 1024 max memory mark. For some reason, I had hoped that CF would finally be written in such a way, that if i set the max memory in the JVM arguments to something higher than 1024, that CF would actually load. No dice. But I digress..the main target of my frustration is Verity aka K2, k2server, k2admin, k2index, and, well, Satan.
We have a fairly significant number of websites, and have heavily used Verity in the past. It's been a pretty good search tool with nice, built-in functionality via the CF tags. However, the day that we upgraded to CF8 (which I've seen listed as a v2.4 to v5.5 upgrade), was quite possibly the worst technical decision that has been made. Apparently, previous versions of Verity shipped with ColdFusion used some kind of "just-in-time" searches, where the actual search was issued against the index files when requested. The current version (shipped with CF8) stores all collection data (or so it seems) within the memory space used by k2server.exe, which is one of the 2 processes spawned by k2admin.exe. This might be nice for search speeds, but doesn't work very well when the process crashes after creating x number of collections. My belief is that the crash is not caused by the number of collections, but by the threads used by k2server.exe, which has a direct correlation to the memory used by k2server.exe. My observation has been that between the 130 and 150 collection mark, k2server becomes unstable, and during the startup (when spawned by k2admin.exe), it rapidly increases its thread count and memory usage. On our servers, this gets to appx 300 threads and 500 MB memory, and then crashes. k2admin.exe is watching the process, and will try to restart it 5 times before giving up and waiting an hour to try again. Initially, i thought this was related to our configuration and our environment, but I've spent a lot of time reading blogs, forums, and general disinformation on the subject, and have seen a constant theme: verity doesn't work if you rely on it.
Now, some will say that I should try building a dedicated verity server. I will argue that this is not a problem with server resources, but Verity's ability to maintain stability with a large number/size/index of collections. I have every belief that we could move the search functionality to its own server, and it would continue to crash.
Alternatively, I've tried using some poorly-documented tools like rcadmin (which, by the way, is the most useful verity troubleshooting tool, but not found anywhere in the Adobe/Verity documentation for CF8). I've tried turning off search caches (searchcacheset), dropped threads (listener and max threads) to 5/1 and everything in between, modified the memory settings (vdksettingset), modified JVM settings (maxPerm, min, XXMaxPerm, etc), deleted the magical ws directory files, restarted services, and sacrificed a chicken. Hell, I've even uninstalled and reinstalled verity a countless number of times (comparable to the "is it turned on" solution), with the original config, and with modified configs. I've done everything that I can possibly think of, and have come to a single conclusion.
Stop using verity. Start using SOLR/Lucene.
I'd be more than happy to have some Adobephiles prove me wrong here. Even better, give me a solution and a reason to keep using this allegedly "fantastic" search product. I've used it for years, and loved every minute...until CF8. Bah.
Copy link to clipboard
Copied
Stop using verity. Start using SOLR/Lucene.
Aparently Adobe may have come to the same conclusion. Which could be why CF9 now utilizes SOLR/Lucene for it's integrated search functionality.
Don't know if that helps you today or not.
Message was edited by: Ian Skinner Edited to include my reply since this forum posted a blank message my first try.
Copy link to clipboard
Copied
CF_Ninja,
I get your point. What you discovered isn't new, and didn't start with Adobe. In fact, it is so common in commercial software, you can even call it a new Murphy's law. If version s is the latest version of a given software(say, Coldfusion 9), and there has been a switch from module m1 in version s-1 to module m2 in version s (say, the switch from Verity in CF8 to Solr in CF9), then the module m1 will invariably be crappy.
The developers of CF8, already with a euphoric eye on the future use of Solr, would inadvertently have ignored any further development of Verity. It's only human to think: Why waste all that effort on an end-of-life product?
I share your choice. The Coldfusion Jedi has a good comparison of Verity and Solr