Releases: Particular/ServiceControl
1.7.0
As part of this release we had 224 commits which resulted in 10 issues being closed.
New Features
#570 Remove ServiceControl.exe command line options for install/uninstall/confguring service
The new ServiceControl Management utility supercedes command line switches provided by the ServiceControl.exe. So in 1.7 the only command line option that will be retained will be option to run the servicecontrol.exe in maintenance mode. This will also be removed at a later date when the management utility presents this option
#459 Allows to override the default "dbo" schema that is used by the SqlServerTransport when creating the queue tables
NServiceBus.SqlServer recently released a new version that allows to override the default "dbo" schema that is used by the SqlServerTransport when creating the queue tables.
#289 Add multi database support for SqlServerTransport feature
Adding multi-database support to ServiceControl, following the same feature added to the SqlTransport (see http://docs.particular.net/nservicebus/sqlserver/multiple-databases).
#572 Redevelopment of ServiceControl Installation
The ServiceControl Installation has been redeveloped to address many of the the limitations of the old installer. The installation now includes a management application which is launched at installation time and is also available from the Start Menu.
Critical Fixes
#501 Retry batching consumes too many resources and crashes ServiceControl
When retrying a large number of messages, ServiceControl maxes the HDD utilization and then memory until a Raven error occurs. This is caused by an unbounded parallel execution during retry batch creation.
If your system deals with large messages you may also need to also adjust Raven/Esent/MaxVerPages
setting to a value higher than 512MB (default). If retrying messages in batches of 1000 and each is 2MB on average then a setting of at least 2048 should be used.
#566 Retries get stuck on a batch when any of the messages fails to be sent
The issue is that if the Send back to endpoint queue fails (it could be because the queue no longer exists because the user has decommission it, or Azure is having a temporary glitch) that causes the batch to never finish and therefore any subsquent batches do not get processed.
How to tell if you are affected?
Read these instructions.
What to do if you are affected
Upgrade ServiceControl to version 1.7.0 or higher.
Download ResetMessageRetry.zip to reset message retries.
Bug Fixes
#527 Allow to override number of maximum concurrent HTTP connections executed under ServiceControl
#568 Corrected sorting of failed messages inside an error group
Where to get it
You can download this release from our website
1.6.3
Critical Patch Release
We discovered a critical bug in ServiceControl related to retrying failed messages.
As part of this release we had 5 commits which resulted in 1 issue being closed.
Bug
- #558 When retrying failed messages, previously archived and resolved messages are also retried
If you have used the Retry All Failed Messages
or Retry Group
functions in Service Pulse, this bug may have sent previously archived messages or resolved messages to your endpoint for reprocessing. Depending on whether your message handlers are idempotent (i.e., processing a message multiple times will have no adverse side effects) there could be an undesirable effect on your systems.
How to tell if you are affected?
We have created a utility called Issue558Detector.exe
to help you determine if you are affected by this bug. This utility will identify the message ids, message types and the endpoints that were reprocessed.
Download the Tools-Issue558Detector.zip and follow the instructions in the README.
You can also download the source of this utility if you need to.
What to do if you are affected?
- Make sure you update to version 1.6.3.
- Our utility will identify affected endpoints and message types. From this information you should be able to infer what handlers were invoked and determine if reprocessing the message would have a negative effect on your system.
- Please contact us via support (http://particular.net/support) and we will work with you to get your situation sorted out.
Where to get it
You can download this release from our website
1.6.2
This release has been withdrawn due to a critical bug, please update to 1.6.3 or higher
As part of this release we had 18 commits which resulted in 2 issues being closed.
Bugs
- #556 ServiceControl runs out of memory when ingesting lots of large messages
- #526 Remove message body when Audit message is expired
Where to get it
You can download this release from our website
1.6.1
This release has been withdrawn due to a critical bug, please update to 1.6.3 or higher
As part of this release we had 20 commits which resulted in 2 issues being closed.
Improvement
- #493 Return null for when TimeSent date is missing
Bug
- #496 Grouping of messages with non-standard stack traces fail
Where to get it
You can download this release from nuget
1.6.0
This release has been withdrawn due to a critical bug, please update to 1.6.3 or higher
As part of this release we had 125 commits which resulted in 9 issues closed.
Improvements
#490 Redesign Bulk Retries
Remove Saga for individual message retries by moving messages to be retried to a staging queue and then forwarding them all at once. This prevents the input queue of Service Control from being flooded with messages when a bulk retry occurs and keeps heartbeat messages from endpoints flowing.
#489 Group Failed Messages by Exception Type and Call Site
Group message failures as they arrive in Service Control by the type of exception that was thrown and the location in the code that the exception was thrown from. Groups of errors can be archived or retried from Service Pulse 1.2.
Failed Messages that were detected with prior versions of ServiceControl will be grouped as a background task when ServiceControl 1.6 starts.
#488 Configure maximum message body size for audit storage optimisation
A new setting was added to ServiceControl that allows administrators to control the maximum size of message bodies that ServiceControl stores in its own internal database.
This facilitates systems that were affected by ServiceControl not storing audited message above 100Kb, which in turn affects the debugging experience when using ServiceInsight.
Up until version 1.6 ServiceControl only stores bodies of audit messages that are smaller than 100Kb by default. After version 1.6 Increase this number to store messages with larger bodies. Messages that have a larger message body in bytes than MaxBodySizeToStore are not stored for audit. This is to ensure that the majority of our users enjoy the best level of performance. For users with special analysis needs, edit MaxBodySizeToStore in ServiceControl.exe.config to increase the size of storeable audit messages
Bugs
#485 ServiceControl cannot retry messages with an empty body (e.g. control messages)
Symptoms
If a control message fails, such as a scheduler timeout, it will go through the FLR and SLR and eventually will end up in the SC database.
The failed message is correctly displayed in ServicePulse but cannot be retried. ServiceControl retry process starts from the assumption that a message will always have a body stored as an attachment.
Who's affected
All users that have failed scheduled messages or deferred messages
#480 ServiceControl 1.5.3 upgrade fails when Azure Storage Queues is the configured transport
Symptoms
Upgrading to a newer version of ServiceControl fails when Azure Storage Queues is the configured transport.
Who's affected
All users that are using AzureStorageQueue
transport and attempt to upgrade to latest.
#472 Duplicate endpoints identified
Symptoms
When a user is not using heartbeats and the system contains multiple versions of NServiceBus core, endpoints are duplicated with incorrect nsb versions.
To replicate, run https://github.com/johnsimons/ReproDuplicateEndpoints
And then go to http://localhost:33333/api/endpoints
And you will see:
[
{
"id": "a692078c-cf7a-dacb-02db-229f77b8ae65",
"name": "Publisher.ComplexSagaFindingLogic",
"host_display_name": "JOHNPC2",
"monitored": true,
"monitor_heartbeat": true,
"license_status": "unknown",
"is_sending_heartbeats": false
},
{
"id": "717ff783-0af5-637d-f194-499f2676c514",
"name": "Samples.ComplexSagaFindingLogic",
"host_display_name": "JOHNPC2",
"monitored": true,
"monitor_heartbeat": true,
"license_status": "valid",
"is_sending_heartbeats": false
},
{
"id": "0f07290e-6f06-a988-abc3-fe6e6d01ec3d",
"name": "Samples.ComplexSagaFindingLogic",
"host_display_name": "JOHNPC2",
"monitored": true,
"monitor_heartbeat": true,
"license_status": "valid",
"is_sending_heartbeats": false
},
{
"id": "50716f66-7914-35bd-abf2-4ef37fd8a207",
"name": "Subscriber.ComplexSagaFindingLogic",
"host_display_name": "JOHNPC2",
"monitored": true,
"monitor_heartbeat": true,
"license_status": "valid",
"is_sending_heartbeats": false
}
]
As you can see Samples.ComplexSagaFindingLogic
is duplicated.
This is running v1.5.2
Who's affected
All users that are using a mix of NServiceBus versions.
#468 Microsoft.Data.Services.Client version problem for Azure Storage Queues
Symptoms
I followed the manual
http://docs.particular.net/servicecontrol/multi-transport-support
But with the latest version of ServiceControl, the Microsoft.Data.Services.Client has an incorrect version. I downgraded the dll and it's working again. Probably good to update the manual with the correct packages. Probably best to make the entire experience a lot smoother :-)
Who's affected
All users that are using AzureStorageQueue
transport
#462 ServiceControl is not logging when an invalid setting is reverted to a default
Symptoms
Some configuration settings have upper and lower settings. Refer docs site for details.
Invalid settings are being handled correctly - when a settings is out of range the default is used. However there is no resulting log entry to indicate that this action has been taken
This leads to some confusion as to why the setting are not working
Are you affected
Users of ServiceControl 1.3 through to ServiceControl 1.5.1
#455 Install Service doesn't work for Azure Storage Queues
Symptoms
Following documentation here: http://docs.particular.net/servicecontrol/multi-transport-support
Using Windows Azure Storage Queues.
When I run the suggested command (using actual values for account name and account key)
:\Your_Installed_Path\ServiceControl.exe --install -serviceName=“Particular.ServiceControl” -displayName=“Particular ServiceControl” -d=“ServiceControl/TransportType==NServiceBus.AzureStorageQueue, NServiceBus.Azure.Transports.WindowsAzureStorageQueues” -d="NServiceBus/Transport==DefaultEndpointsProtocol=https;AccountName=[account-name];AccountKey=[account-key];"
I get the following error from ServiceControl
Error: Found 3 option values when expecting 2.
ServiceControl by Particular Software
The issue is because my base64 encoded account key ends with == (eg XXXXX/XXXXX+XXXXX....XXX==). If I remove the trailing == from the account key, ServiceControl starts to install but it eventually fails since the key isn't correct.
It looks like your command argument parser is treating == as a token, rather than part of the connection string value
Who's affected
All users that are using AzureStorageQueue
transport and have a key that ends with ==
.
Where to get it
You can download this release from our website
1.5.3
As part of this release we had 7 commits which resulted in 2 issues being closed.
Improvement
#467 Added ETAG to requests for message bodies to allow caching in ServiceInsight
This change allows for a performance enhancement in ServiceInsight
Bug
#477 Transaction timeouts can occur when executing RetryAll
Who's affected
Everybody having a large load of messages to be audited.
Symptoms
ServiceControl is wrapping the consumption of messages in a TransactionScope with the default transaction timeout settings set to 30 seconds. When a large number of messages need to be processed it can happend that those retries take longer than 30 seconds thereby leading to TransactionAbortedException.
The fix is to no longer wrap consumption of messages in a TransactionScope.
Where to get it
You can download this release from:
- Our website
- Or chocolatey
1.5.2
As part of this release we had 1 issue closed.
This release addresses an error in 1.5.1 which prevented the installation of ServiceControl from succeeding when an upgrade was carried out
Bugs
#461 ServiceControl 1.5.1 Install fails on upgrade due to missing RavenDB index
Symptoms
ServiceControl 1.5.1 fails to install when upgrading from an older version. A fresh install using a blank database works correctly
A race condition in the RavenBootstrapper class is the cause of this failure.
The RavenBootStrapper creates all indexes asynchronously but then attempts to use the KnownEndpointIndex straight away. KnownEndpointIndex was introduced in 1.5.1.
Who's Affected
Anyone attempting to upgrade an existing ServiceControl to v 1.5.1 may have been affected
Content trimmed. See full issue
Where to get it
You can download this release from:
- Our website
- Or chocolatey
1.5.1
As part of this release we had 2 issues closed.
Fixed Bugs
#445 ServiceControl service stops after failing to import messages
ServiceControl 1.4.x through to 1.5 fails to start and the following exception is logged:
NServiceBus.Unicast.Transport.TransportReceiver Failed to process message System.Collections.Generic.KeyNotFoundException: The given key was not present in the dictionary.
#448 HeartbeatStatusInitializer throws exception when ServiceControl starts
The ServiceControl logs have the following exception present:
ServiceControl.HeartbeatMonitoring.HeartbeatStatusInitializer, ServiceControl, Version=1.0.0.0, Culture=neutral, PublicKeyToken=null could not be started.
System.InvalidOperationException: Sequence contains more than one matching element
Who's affected
This update targets bugs that are present in multiple versions of ServiceControl so it is a recommended upgrade for all previous versions,
Upgrading from ServiceControl 1.4.x or below
Version 1.5 introduced changed the default installation behavior by introducing a new mandatory command line switch for the installation when run in "silent" mode. Please review (#333) and the associated installation documentation if you are upgraded a version prior to 1.5
Where to get it
You can download this release from:
- Our website
- Or chocolatey
1.5.0
This release of ServiceControl changes the default installation behavior and introduces a new mandatory command line switch for the installation when run in "silent" mode, Please review the release notes for #333 and the associated installation documentation
Feature
- Added CustomCheckSucceeded and CustomCheckFailed event publishing for external integration #444
Improvement
- Audit message forwarding should be a mandatory choice during installation or upgrade if it isn't set in Production #333
Bugs
- ServiceControl creates duplicate messages in the DB if the log queue is not writable #440
- Failure in processing audit messages may result in message loss #432
Where to get it
You can download this release from:
- Our website
- Or chocolatey
1.4.4
As part of this release we had 2 issues closed.
This hotfix addresses bugs with ServiceControl external integration.
Fixed Bugs
- #438 MSMQ Messages from 3rd party integration are not available via the REST API
- #427 ServiceControl stops shortly after starting
Symptoms
For #438 the symptoms are:
- ServiceControl is version 1.4 or above
- The ServiceControl service starts and then stops within a two minutes.
- multiple 'KeyNotFoundException' exceptions logged for ServiceControl.ExternalIntegrations.EventDispatcher
For #427 the symptions are:
- Failed messages from non-NServiceBus endpoint usng MSMQ are visible in ServicePulse but the headers and body information are not available.
Who's affected
This hotfix is applicable to any users who are running ServiceControl 1.4 or greater or any user who is using ServiceControl to monitor a system comprising a third party integration that sends MSMQ messages to NServiceBus endpoints. For user affected by #438 this is a critical bug fix
Where to get it
You can download this release from:
- Our website
- Or chocolatey