Numerous times in recent years I’ve had to use Reflector Pro to debug third-party dlls. While this works well and allows you to step through code as if it was your own the value of doing so can be completely lost if you cannot see critical object values due them being ‘optimized away’.
Recently I was stuck with a problem of optimization that refused to be disabled by the usual means that I’d used in the past. I stumbled onto a neat trick which finally did work, but it also clarified what happens when the web application, usually Sitecore CMS, restarts.
I setup a Mongo arbiter instance alongside two full instances for use with Sitecore 8 xDB database. Shortly afterwards I noticed the arbiter log was full of authentication failures. This isn’t a big huge problem, but it fills up the arbiter log and may cause concern wondering if there’s an underlying configuration problem.
Way back in June 2012 I wrote about how you could set QoS (Quality of Service) DSCP values on Crashplan traffic on Windows, not by using the ineffective settings within Crashplan, but by using the group policy tool to tag traffic coming from the CrashplanService.exe process itself. In other words, I never found a way to make the Crashplan setting work, but the work around was pretty solid.
Earlier this year I acquired a Synology DS415Play diskstation, a decent NAS which could store the constant accumulation of photos, video clips and music, but I also installed the excellent Crashplan package from PCLoadLetter on it in ‘headless’ fashion using Scott Hanselman’s guide. Shortly afterwards I again needed to tag the crashplan traffic with a DSCP value so that the bulk upload traffic could be deprioritized to prevent it crippling my internet connection for other contending devices.
This post explores how to work around a serious bug (again!) in the Crashplan QoS settings, monitor the traffic via ssh and finally being able to successfully set the Differentiated Services Code Point (DSCP) values for upload traffic for QoS. This then allows you de-prioritize Crashplan traffic at your router and so leave you internet connection fast and responsive for other clients and applications. See previous post of how to do this with a Draytek SOHO router.
Sitecore uses the extensive log4net logging framework to handle the large volume of logging entries it generates. Sometimes vague log entries can leave you scratching around trying to find where they originated from. This post explores some simple steps to add useful detail to, and real-time viewing of, the Sitecore log.
Using the new Sitecore contentsearch api allows you search against a lucene index with very little effort. Examples are a bit short on the ground but using Linq you can find yourself doing something like this to search for an item by name, somewhere within a folder structure:
public void BadSearch(string searchTerm)
var webIndex = ContentSearchManager.GetIndex("sitecore_web_index");
using (var context = webIndex.CreateSearchContext())
var results = context.GetQueryable<SearchResultItem>().Where(i =>
i.Name == searchTerm &&
i.Path.StartsWith("sitecore/content/stuff/")); // don't do this!
This may well work. However you may also run into a Lucene error stating that you are using too many clauses, the default limit is 1024.
I spent far too long figuring out how to do this not share it. Running an online backup service (Crashplan) on my laptop was killing my network for everything else that was using it. I documented in a previous post how to set DSCP packet headers on Windows 7 for Crashplan. This post is about the next step of doing something actually useful in the router. Continue reading →
Update 2013-05-30: The solution described at the end of this post is applicable to Windows 7 Professional and other non-‘home’ editions. Windows 7 Home Editions do not appear to have group policy editor (gpedit.msc) installed as standard.
I spent a fair amount of time trying to get to the bottom of this and so thought I would share my experiences, and partial successes. This post describes the issues I had trying to stop Crashplan’s upload traffic slowing down everything else on the network while utilising the available bandwidth for very large uploads. It talks about Differentiated Services Code Point or DSCP, QoS, Netmon packet monitor, Group Policy settings, and various unsuccessful fixes to the problem of Crashplans DSCP setting having no apparent effect either due to a bug or limitations of Windows 7. This post doesn’t discuss router configuration (to be part of a separate post), just Crashplan and DSCP on Windows 7.