Month: January 2017

Posted on

Coveo Zero Results Issue

First, based on project requirements on Coveo version you have installed all Coveo components, hooked up your sitecore to use Coveo and all is well on Diagnostics. All components are Green.

Now, you drop or use newly and successfully built index for your search queries, you get zero results back.
Why would it return zero results, is it picking incorrect index? Are my configurations fine? Then you go the good old CES console to see if there are any errors.  Except for query returning 0 results, there are no errors.
But, I note this on the CES console –

Query (@fz95xlanguage76852==”en”) (@fz95xpath76852==3ab17f3f16be4a018105ecade4380857) (@fz95xtemplate76852==f5cc486b394c40ff8320480ec7c650a7) performed by extranetAnonymous [Sitecore Security Provider for blah-blah.com]. 0 results in 0.016 seconds.

I copied the query and ran it in Index Browser on CES Administration tool.  It did return loads of results.  So, it is not data, it is there for sure and query is correct as well.

Seems like the query was run by Anonymous user.  So, few check points to ensure this is not permissions issue.

  1. Ensure extranet/anonymous user on sitecore instance have read permissions on the content tree 
  2. Go to Index Browser and run the query above, go to any of the search results and look for permissions tab under Details.  It should show who all have access to this item.  
  3. You should see ‘Anonymous’ there.  If Anonymous is not there, that could be a problem and which is why the results come back as ‘0’.  I did not see this user in permissions and started scrambling on what I can do to fix this.  I came across the below blog 
The problem stated there looked exactly like mine.  I did the last step which is to clear caches on Details Tab under content security and once I did that, I could now see anonymous under permissions in individual documents. 
All is well and no more empty results. 
Query (@fz95xlanguage76852==”en”) (@fz95xpath76852==3ab17f3f16be4a018105ecade4380857) (@fz95xtemplate76852==f5cc486b394c40ff8320480ec7c650a7) performed by extranetAnonymous [Sitecore Security Provider for blah.com]. 203 results in 0.031 seconds.

Posted on

Debugging CD issues – No matching constructor was found

Most of the times, when you set up a CD server at some point or the other.  You will see errors like ‘No matching constructor found….’
These nasty errors are hard to debug specifically if you have bunch of complex third party system’s interacting with your sitecore instance. I encountered something like this while setting up our pre-production environment with load balancer going on.  If you choose to do trial and error, these errors could take for ever to resolve.  
I applied a strategy and that seemed to get me to the problem more quickly.  Also, I felt the strategy is generic, so, it could be applied to any error similar to this kind.
 
So, here is the error I had to battle – 
Could not create instance of type: Sitecore.ContentSearch.LuceneProvider.LuceneIndex. No matching constructor was found.
 
Here are the steps I took to resolve this.  Hopefully, it will help some one scrambling for a resolve. 
 
Go to sitecoreinstance/sitecore/admin/showconfig.aspx and ensure there are no references to ‘master’ any where, since this is a CD after you enable Switch master to web config and you did a good job at it, you should not be seeing any references.  If you do, then, revise your config. 
 
After you eliminate #1, check for which constructor it is is complaining about.  In my case it was Sitecore.ContentSearch.LuceneProvider.LuceneIndex.  So, I pulled up the *.dll specific to this that comes with Sitecore installation using reflector. 
 
If you notice – there are three constructors I could see from what reflector has to say –  In this case the below:
protected LuceneIndex(string name);
public LuceneIndex(string name, string folder, IIndexPropertyStore propertyStore);
public LuceneIndex(string name, string folder, IIndexPropertyStore propertyStore, string group);
 
Next, I opened up sitecoreinstance/sitecore/admin/showconfig.aspx again and went through all entries on the config that inherit or have provider listed as Sitecore.ContentSearch.LuceneProvider.LuceneIndex to check and see if they are passing the params to adhere to one of the three the *.dll supports.  
 
There were only about nine references, so, it was not such a pain to see each of those to compare.  I found one entry that was not passing params per expectation.  You should also see from which patch file this entry is coming from.  Thank you Sitecore.
 
I deleted that entry as I did not need it as the original config file from which this index was originally defined was disabled per Sitecore set up instructions.  But, in your case if you need that entry, ensure you are passing in params that would match atleast one constructor. 
 
That’s all!! Error behind us and I could go back to sleep peacefully.  This strategy could be applied to any error you will face.  The fact is trial and error is not so much fun and application of clear strategy shows you understand what you are doing. 
 
Hope this helps someone!!!