Documentation Center

Background Task Introduction

Introducing the centralized Background Task system that replaces the decentralized Microsoft Message Queuing (MSMQ) system.

General

By introducing the Background Task system, we offer a full replacement of the previously used Microsoft Message Queuing system (MSMQ). This means we no longer require:
  • InfoShareConfig.xml and its registry entry ConfigurationFile is fully obsolete and completely replaced by a central Xml Settings database driven configuration file.
  • Activators for the Trisoft-InfoShare-Author COM+ server application like \Applications\Maintenance\RestartCOMTrisoftInfoShareApp\ or \Applications\Maintenance\WakeUpIshComponents are no longer required.
  • QDispatcher is obsolete, as the new system relies on a centralized database queue. The old system relied on a decentralized per WebApp server with only forwarding capabilities through InfoShareConfig.xml.
  • Listeners on the Trisoft-InfoShare-Author, typically set to 3. This setting was always on the conservative side as 3 megapublish operations could make your server come to a halt. But because there was no message distinction 3 listeners for simple background tasks means that your server resources potentially were underutilized at times.
Some features we introduce are:
  • Database centralized Xml Settings configuration (\Websites\Author\EnterViaUI\Admin.XMLBackgroundTaskConfiguration.xml), so a single point of configuration. Through Windows environment variable settings, we still allow per server changes. On top you can set extra environment variables like installation paths in \Applications\BackgroundTask\Bin\BackgroundTask.exe.config.
  • Matrix based polling with maximum executions per message type, server or server role - if desired. By default we will restrict the number of publish operations to 2 in parallel, but we will at the same time also allow 2 translation management operations, a synchronize and 2 other (customer) types. So in this example up to 7 tasks are handled in parallel allowing various message types to make progress. Configuring the number of parallel executions protects the available server resources.
  • Scalability and fairness based on the central database queue.
  • The basic principle is that a background task will be leased. This allows lease refreshes, lease time outs and hence recoveries without administrator interventions.

Flow

The service picks up a background task entry from the central database queue by leasing it. A lease consists out of marking a background task entry in the database with the identifiers of the service that picked up the task (LEASEDON and LEASEDBY). This execution gets @timeout time to successfully complete the task. If the task doesn't get marked as completed and unleased within this @timeout value; any other service having <leaseRecovery> enabled will be allowed to do recovery of this entry. To avoid racing conditions, a system can only recover if the lease time plus the @timeout plus the @recoveryGracePeriod is in the past from the current time stamp.

All new code - like DocumentObj25 and PublicationOutput25 - will execute a database transaction per object to minimize lock times. This means that for example a group status transition of 89 objects could trigger 89 email notifications. To allow aggregation of these background tasks request we introduced an <aggregation> handler. Typically this aggregation is done within the synchronous code part, so the plugin. Suppose only 70 of the 89 objects were submitted, then a service having <aggregationRecovery> enabled will attempt to recover the aggregation of those 70 objects after @gracePeriod time.

Standard HashId functionality that allows skipping of outdated background task entries. For instance when a user saves a topic x times to the master repository, it will trigger an equal amount of synchronization attempts to the slave repository. In this case only the last synchronize matters and will be executed. The HashId is chosen by the handler implementation that puts the message in the background task system - typically a plugin will use the language card id.

Configuration

Every handler can be separately set per group per service role. So it is possible to create a service role Publish which only takes the handlers required for publishing. And use this service name on certain Background Task services to make them dedicated for publishing. Out of the box we configure a service with a role named Default that is configured to execute all types per service. You will notice the role value Default on the command line that starts up the Windows service.

Every service role feature can be separately enabled through configuration flags like @leaseRecovery, @poller and @aggregationRecovery. This allows to set up service roles that specifically handle recovery or polling of publish operations only, because you only have publish software licenses available on some boxes.

Out of the box we configure a service with a role named Console. If you activate this after installation on the server through \Applications\BackgroundTask\Configuration\StartConsole.bat, the command line option specifies the @role to look up in the centralized configuration. By default this is set to Console. This special setup will only do one task at a time; and it is a good start to analyze misconfigurations.

Per handler like EXPORTFORPUBLICATION you can specify various dimensions like @isolationLevel or @timeout. When errors occur you can specify how many retries (@maximumRetries) are allowed, and you can also state if it should retry for specific error numbers or immediately fail. This allows future optimization scenarios like for example a system is down when receiving error number X, when X occurs retry the execution but with a @delay or just never retry anymore.

Server Artifacts

A new Windows service named Trisoft InfoShare#!#installtool:PROJECTSUFFIX#!# BackgroundTask One will be installed on every system. The service runs BackgroundTask.exe that processes background tasks requests. The service can trigger auxiliary BackgroundTaskIso.exe which will host isolated execution of background task requests.

The number of COM+ applications visible in Component Services has been reduced from 3 to 2. Trisoft-InfoShare-Author no longer triggers MSMQ listeners. Trisoft-InfoShare-AuthorIso changed from a server to library application. Trisoft-InfoShare-AuthorGrp has been removed.