Back in February this year I gave a presentation at the London Sitecore User Group “Improving the Solr Content Search Provider”.
My first talk at a Sitecore User group.
Although I regularly attend the Sitecore discussion club, and have presented there on several occasions.
At the presentation I included a link to a github repository with a list of known issues and their public reference numbers.
The list of issues will vary between Sitecore versions, I’ve included the list of issues I’ve come across between Sitecore 8.2 up to Sitecore 9.0 update 2.
Including:
The github repostiory also included an example implementation of patterns to address some of the fallacies of distributed computing.
Related blog posts:
On reasons not to use each of them, at least on Content Delivery, or when querying over lots of items.
Changing MyItems & Unlock all to use Solr, rather than a Sitecore Query.
I told you Sitecore.Query was slow, and Memory Intensive.
Infact since giving this talk, one of the issues that got me to customise the Sitecore Solr Search provider in the first place reared its head again. Sitecore not being able to startup when Solr is down.
Well the number of Sitecore indexes had grown over time.
On startup each index was doing it’s own check to see if Solr was available, and waiting for a timeout/exception. This was happening in series. Depending on the type of error you get, if it’s a timeout, this can result in Sitecore taking longer to startup than IIS allows. Causing IIS to recycle the application and try again, in an infinite loop. Oh dear!
So I’ve added to the github repository a new issue 314454 - Sitecore doesn’t startup when Solr Down.
You can simulate on your local PC latency to Solr using Fiddler. If you change your solr connection string to
http://localhost.:8983/solr;solrCloud=true
Notice the “.”, will ensure the traffic goes through Fiddler
Change your Sitecore IIS Application Pool to run as your local user, as Fiddler automatically picks up traffic running as your local user. (Or you can change the proxy settings)
Then run Fiddler.
Under “AutoResponder” tab, you can add a Rule for requests matching
http://localhost.8983/solr/.....
The URL you set could be specific to a particular index, or request, depending on what you want to test.
Then on the response for that URL you can set
*delay:10000
with how many milliseconds you want to delay the request with.
Using this technique you can simulate a network timeout, rather than a quicker port not listening/service not running error.
And from this can replicate the issue of Sitecore note being able to start up, if you have enough indexes which all timeout on startup.
Sitecore doesn’t issue patches anymore, so instead you get a hotfix, which include all of the issue fixes for that version of Sitecore you are on.
For Sitecore 9.0 update 2, this was included in hotfix 323662-1.
And included changes to dlls
There were so many changes it felt like a mini Sitecore Upgrade. And the contract changed, had to rewrite our customisations for them to continue to work.
This hotfix fixes the slow startup issue, but only checking once if Solr is available, rather than per index. So make Sitecore much faster to startup when Solr is down.
There was also some work to make the initialising of the indexes to work in parallel, to further speed up the time for initialisation.
Each time we upgrade, we have to see if our customisations are still possible. Often the extension points/hooks we have used have gone, and we have to find new ones.
Even on this update to the hotfix which address 314454, we had to do a lot of rework.
Hopefully in a future version of the product the extensions points we require will be included in the product, and we won’t have to get out dotpeek to find a place to override, and use reflection/so many custom classes and overrides to change the behaviour to what we need.
As the hotfix isn’t publicly available in the nuget feeds, and the contract has changed.
I can’t update the example code to reference the hotfix, and for it to still compile.
If anyone is interested to see the examples updated to use the hotfix, reach out to me on twitter, and I can see about creating a feature branch.
Otherwise, I’m going to wait for a version of Sitecore which includes these fixes/contract changes, which is available in the nuget feed so I can update the examples and still have it compiling.