Sitecore

Understanding Sitecore logs – Part 5: Thread Pool Size Monitor, Rebus, Assembly Resolver, MVC Area Registration and XML Configuration Load

Joao Neto

Joao Neto

— 4 min read
Understanding Sitecore logs – Part 5: Thread Pool Size Monitor, Rebus, Assembly Resolver, MVC Area Registration and XML Configuration Load

Continuing with my series of blogs describing what each line in the Sitecore logs mean, today I want to talk about Thread Pool Size Monitor, Rebus, Assembly Resolver, MVC Area Registration and XML Configuration Load.

In this post, we are still examining the log file. In future posts, we will explore Client, Crawling, Eds, Exm, Fxm, Search, Publishing, Aggregation and WebDAV logs.

If you missed the first part of my series, please have look at

Thread Pool Size Monitor

405248 13:27:12 INFO  Initialized ThreadPoolSizeMonitor with parameters accelerationRate: 50, decelerationRate: 1, updateInterval: 00:00:00.5000000
405248 13:27:12 INFO Start thread pool size monitor in the background
405248 13:27:12 DEBUG Increased min threads to {0}
405248 13:27:12 DEBUG Cooling down. {0} threads are active
405248 13:27:12 DEBUG Min threads: {0}, Active threads: {1}.
405248 13:27:12 ERROR Exception occured in ThreadPoolSizeMonitor

These logs are created by the class Sitecore.Analytics.ThreadPoolSizeMonitor located in the Sitecore.Analytics assembly.

Thread Pool Size Monitor’s role is to manage the thread pool through the methods in the static class System.Threading.ThreadPool. This .NET class provides a pool of threads that can be used to execute tasks, post work items, process asynchronous I/O, wait on behalf of other threads, and process timers. Putting it simply, this monitor basically controls the minimum and maximal number of threads in the application.

The thread pool size monitor is initialized by the pipeline Sitecore.Analytics.Pipelines.Loader.StartThreadPoolSizeMonitor upon application start. It is defined in the configuration file \App_Config\Sitecore\Marketing.Tracking\Sitecore.Analytics.Tracking.config.

This pipeline takes 3 parameters with the following default values:

  • accelerationRate: 50
  • decelerationRate: 1
  • updateInterval: 500

Rebus

The following entries are logged by an open-source library called Rebus.

400720 13:27:13 INFO  Database already contains a table named "[dbo].[Sitecore_EXM_AutomatedMessagesQueue]" - will not create anything
400720 13:27:13 INFO  Mapped Sitecore.EmailCampaign.Model.Messaging.AutomatedMessage -> "Sitecore_EXM_AutomatedMessagesQueue"
400720 13:27:13 INFO  Starting periodic task "ExpiredMessagesCleanup" with interval 00:01:00
400720 13:27:13 INFO  Starting periodic task "CleanupTrackedErrors" with interval 00:00:10
400720 13:27:13 INFO  Database already contains a table named "[dbo].[Error]" - will not create anything 400720 13:27:13 INFO  Table {tableName} does not exist - it will be created now
400720 13:27:13 INFO  Setting number of workers to 1
400720 13:27:13 INFO  Bus "Rebus 1" started
400720 13:27:13 INFO  Messaging : IMessageBus started successfully : 'Sitecore.EmailCampaign.Model.Messaging.Buses.AutomatedMessagesBus'

Rebus is a service bus implementation for .NET and it is what the Sitecore Message Bus uses to enable communication between the application roles. According to the official documentation, here is how the message bus is referenced by the other roles:

By default, the messaging transport uses SQL Server Databases. You can see it in the web.config the entry.

<add key="messagingTransport:define" value="SQL" />

However, it is possible to use Azure Service Bus.

<add key="messagingTransport:define" value="AzureServiceBus" />

Note: Azure Service Bus is the default option when you install Sitecore on Azure using the Sitecore Azure Toolkit. It is also possible to switch it to use SQL Server Databases.

The Rebus assemblies responsible for those entries in the log are listed below:

  • Rebus.SqlServer. DbConnectionProvider, Rebus.SqlServer
  • Rebus.SqlServer.Transport. SqlServerTransport, Rebus.SqlServer
  • Rebus.Routing.TypeBased, Rebus
  • Rebus.Threading.SystemThreadingTimer, Rebus
  • Rebus.Threading.TaskParallelLibrary, Rebus

Assembly Resolver

405248 13:27:12 INFO IAssemblyResolver contains 197 assemblies
405248 13:27:13 INFO [Sitecore Services]: IAssemblyResolver contains 281 assemblies

These two entries come from two different places.

Firstly, it comes from a static class named MvcSettings (located in the Sitecore.Mvc.Configuration namespace) that registers a number of assemblies for internal usage – almost a container for a dependency injection, but not actually one.

Sitecore, through the DefaultAssembliesResolver (System.Web.Http) reads all the assemblies in the /bin folder. Then the FilteredAssembliesResolver (Sitecore.Web) filters out the assemblies defined in the configuration node /configuration/sitecore/mvc/configurationAssemblies/excludedAssemblies. This configuration is found in the file \App_Config\Sitecore\Mvc\Sitecore.Mvc.config.

Finally, the LoggingAssembliesResolver logs the first entry with – in my case – 197 assemblies.

Secondly, it comes from the internal class ConfigurationSettingsAdapter (Sitecore.Services.Infrastructure). It does a similar process as the MvcSettings, but it reads the assemblies to filter out from /configuration/sitecore/api/services/configuration located in the file \App_Config\Sitecore\Services.Client\Sitecore.Services.Client.config.

MVC Area Registration

405248 13:27:13 INFO [Sitecore Mvc]: Registered area : Coffeely
405248 13:27:13 INFO [Sitecore Mvc]: Registered area : Solmusic

These entries are simply showing what ASP.NET MVC Areas of your application have been registered.

Sitecore will by default register all areas in the initialize pipeline Sitecore.Mvc.Pipelines.Loader.InitializeRoutes, Sitecore.Mvc. The way Sitecore registers Areas is the same way as the normal ASP .NET MVC Application does, but with the caveat of limiting the scope of assemblies that it will search for areas to the ones filters in the static class MvcSettings (see previous section).

If you want to add specific areas that should not be registered in the initialize pipeline, you can add a patch to the following node /configuration/sitecore/mvc/areas/excludedAreas. In the file \App_Config\Sitecore\Mvc\Sitecore.Mvc.config you can see an example:

<excludedAreas>
  <area type="Sitecore.Social.Client.Mvc.Areas.Social.SocialAreaRegistration, Sitecore.Social.Client.Mvc" />
</excludedAreas>

XML Configuration Load

ManagedPoolThread #7 13:27:13 INFO  Trying to load XML configuration /App_Config/Security/Domains.config
ManagedPoolThread #4 13:27:13 INFO  Trying to load XML configuration /App_Config/Security/GlobalRoles.config

This log entry is registered by the Sitecore.Configuration.XmlConfigStore, Sitecore.Kernel. Sitecore loads internally all the configuration files defined in the node /sitecore/configStores - \App_Config\Sitecore.config.

<configStores>
    <add name="domains" type="Sitecore.Configuration.XmlConfigStore, Sitecore.Kernel" factoryMethod="LoadFromFile" arg0="/App_Config/Security/Domains.config" />
    <add name="globalRoles" type="Sitecore.Configuration.XmlConfigStore, Sitecore.Kernel" factoryMethod="LoadFromFile" arg0="/App_Config/Security/GlobalRoles.config" />
</configStores>

If anything goes wrong, you are going to see a log entry such as the one below:

Configuration file is missing a root element (/App_Config/Security/Domains.config)

That’s all for today.

Credits

Photo by Joel & Jasmin Førestbird on Unsplash

comments powered by Disqus

Read more