Verity Collections Stalling

All: I'm maintaining a client's CF server (CF Standard 8 on Win2k3) and have been running into a weird problem that I can't figure out.  The website has a number of Verity collections defined, all of which are used from a single search interface.  The search itself works fine but, every now and then (seemingly randomly), a collection (which one also seems random) will seem to stall for lack of a better word.  This causes any searches against that particular collection to fail with the following error:                There was a problem executing the cfSearch tag with the following collections. Collection (status code): teachers (-1705) <br>The error occurred on line 28. The code on line 28 is simply the cfsearch tag being used to perform the search.   The only thing that seems to get around this issue is to delete the collection, recreate it, and reindex it.  This gets it working again until it once again stalls.  A few times, the CF Administrator wouldn't allow me to delete a collection until I had restarted the CF service first but, usually, this isn't required. Any ideas what could be causing this or even where I could begin looking to diagnose the problem?  I'm never made aware of the problem until someone tries to run a search against a stalled collection so I only get error information for the error after the fact.  But none of the logs seems to show anything that would cause this either. Thanks in advance. -- Mosh Teitelbaum evoch, LLC http://www.evoch.com/

Check the event log for issues with the search service. Check the.cfusion runtime logs also indication of service issues. C:/coldfusio/runtime/logs Regards Russ Michaels On Aug 20, 2012 9:55 PM, "Mosh Teitelbaum" <mosh.teitelbaum@evoch.com> wrote: ----- Excess quoted text cut - see Original Post for more -----

I actually have an exception handler to deal with this very problem... It's pretty specific to our system but you'll get the idea...       <cfcatch>         <!--- Refer to the K2 Client Programming pdf for error codes --->         <!--- -1705 means the collection is offline - we only see this error when we are re-indexing the entire catalog. --->         <!--- -2 means a generic fail - Only restarting the Search Service fixes this error. --->         <cfif cfcatch.Detail DOES NOT CONTAIN "(-1705)" AND             cfcatch.Detail DOES NOT CONTAIN "(-2)">           <cfset fireEvent("CheckCatalogIntegrity", Struct(catalogName=variables.instance.catalog,criteria=arguments.criteria,se archType=arguments.searchType), true)>           <cfset mailArguments("Integrity check", arguments, variables.instance, cfcatch)>         <cfelseif cfcatch.Detail CONTAINS "(-2)" or               cfcatch.Detail CONTAINS "cannot make connection to server at: k2://localhost:9921">           <cfset fireEvent("restartSearchService", Struct(catalogName=variables.instance.catalog), true)>           <cfset mailArguments("Search Service Failed. Restart requested.", arguments, variables.instance, cfcatch)>         </cfif>         <cfset q = QueryNew("none")>       </cfcatch> The fireEvent function launches threads so the CheckCatalogIntegrity and restartSearchService functions are launched without slowing the user experience down and we get some nice debug when the problem occurs which isn't too often thankfully. CheckCatalogIntegrity does that by carrying out another search using the same search terms. If it fails for a second time, the catalog is automatically rebuilt. restartSearchService runs a custom batch file to restart the CF search service. In addition to that info, the Verity K2 Client Programming Guide may come in helpful for any other error codes you may come across... http://newmediadev.typepad.com/files/verity-k2-client-programming-guide.pdf HTH Paul All: I'm maintaining a client's CF server (CF Standard 8 on Win2k3) and have been running into a weird problem that I can't figure out.  The website has a number of Verity collections defined, all of which are used from a single search interface.  The search itself works fine but, every now and then (seemingly randomly), a collection (which one also seems random) will seem to stall for lack of a better word.  This causes any searches against that particular collection to fail with the following error:                There was a problem executing the cfSearch tag with the following collections. Collection (status code): teachers (-1705) <br>The error occurred on line 28. The code on line 28 is simply the cfsearch tag being used to perform the search.  The only thing that seems to get around this issue is to delete the collection, recreate it, and reindex it.  This gets it working again until it once again stalls.  A few times, the CF Administrator wouldn't allow me to delete a collection until I had restarted the CF service first but, usually, this isn't required. Any ideas what could be causing this or even where I could begin looking to diagnose the problem?  I'm never made aware of the problem until someone tries to run a search against a stalled collection so I only get error information for the error after the fact.  But none of the logs seems to show anything that would cause this either. Thanks in advance. -- Mosh Teitelbaum evoch, LLC http://www.evoch.com/

Russ: Thanks for the suggestions.  Unfortunately, none of the log files, nor the Windows Event Log, shows anything related to the search service.  The log files show the error once someone tries to perform a search against a stalled collection but nothing about the collection when it stalls. -- Mosh Teitelbaum evoch, LLC http://www.evoch.com/ Russ Michaels wrote: > Check the event log for issues with the search service. > Check the.cfusion runtime logs also indication of service issues. > C:/coldfusio/runtime/logs

perhaps this might be a good time to convert to SOLR then seeing as verity is no longer supported On Tue, Aug 21, 2012 at 3:20 PM, Mosh Teitelbaum <mosh.teitelbaum@evoch.com>wrote: ----- Excess quoted text cut - see Original Post for more -----

Paul: Thanks for the response.  I may end up implementing something like this if all else fails but I'd prefer to find the actual cause of the problem to prevent this from happening in the first place instead of responding after the fact.  Any ideas what could be causing the collections to stall? Thanks. -- Mosh Teitelbaum evoch, LLC http://www.evoch.com/ Paul Vernon wrote: > I actually have an exception handler to deal with this very problem... > > It's pretty specific to our system but you'll get the idea...

> Paul: > > Thanks for the response.  I may end up implementing something like this if all else fails but I'd prefer to find the actual cause of the problem to > prevent this from happening in the first place instead of responding after the fact.  Any ideas what could be causing the collections to stall? Seriously, that solution is what I came up with after spending more time than I'd like to admit to looking at Verity. In the end, I came to the conclusion that the version of Verity baked in to CF simply isn't up to the job of heavy load search queries when it's handling multiple catalogs. I ended up writing the exception handler so that I wasn't caught out with a downed search service simply because Verity lost the plot. By doing what I've done, I haven't had to manually manage the collections in around 5 years. Even the full removal of catalogs and their subsequent rebuild is automated if it escalates to that. One of the weirdest things that Verity does is get its catalogs mixed up... Sometimes you can search against one catalog and verity returns results from a completely different one. Not clever. All our servers are CF8 at the moment and I'm running CF 10 on the dev laptops at the moment with CF8 in staging. As soon as I can get the staging server and production servers over to CF10, I'll dump Verity for Solr in a heartbeat. All my search code and catalog management is wrapped up in a set of objects so I can swap out the low level verity.cfc for a solr.cfc that has the same functions with Solr specific implementations and all the rest will "just work". Can't wait. Paul

Paul: Not happy to hear that but I suppose it's better than continuing to rip my hair out.  Thanks for the help. -- Mosh Teitelbaum evoch, LLC http://www.evoch.com/ Paul Vernon wrote: ----- Excess quoted text cut - see Original Post for more -----