Skip to content

1.6.0
Compare
Choose a tag to compare
@particularbot particularbot released this 11 Aug 01:14
· 5955 commits to master since this release
1.6.0
09491a2

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

Assets 2
Loading