ServiceControl 3.1.1 and 2.1.4 - Patch releases available


(Szymon Pobiega) #1

Hi everyone,

We’ve just released ServiceControl 3.1.1 and 2.1.4.

Fixed Bug

  • #1390 PowerShell cmdlet Invoke-ServiceControlInstanceUpgrade throws exception

Who’s affected

All users who manage their ServiceControl instances using PowerShell cmdlets.

Should you upgrade immediately

This update can be applied during the next maintenance window and does not need to be applied immediately.

Where to get it

You can download this release from our website.

With thanks,

The team in Particular

Please read our release policy for more details.

(Edward Dewe) #2

We are very pleased to be getting native AWS SQS asupport for ServiceControl. I tried installing this for my ‘dev’ sandbox environment and this has raised some questions around the configuration…

We use an SQS queue name prefix to ensure we don’t get queues being re-used across environments.

When you run the Service Control installer tool for the SQS transport you can deliberately set the error and audit queues to alternate values, which we can use to align with our environment specific queue name prefixes. The native service control queue (Service.Control) is not configurable though (as far as I can see) so that would mean all our ServiceControl installations across environments (including dev sandboxes) will end up competing over the same Service.Control queue?

Have a missed something?

Kind regards,


(Szymon Pobiega) #3


The main queue name is based on the selected Windows service name (defaults to Particular.ServiceControl). You can change the service name to e.g. TestServiceControl and the queue name will have the Test prefix.

Hope it helps,

(Edward Dewe) #4

Hi Szymon - thanks for that. We have service control up and running under SQS. All the audit and error messages it is consuming are failing out to the servicecontrol poison/error queue with the following error:

2018-09-17 12:03:15.7536|76|Warn|NServiceBus.Transports.SQS.MessagePump|Treating message with SQS Message Id 4d6ee26c-ac3d-41a7-be4b-7099f2595b24 as a poison message due to exception Newtonsoft.Json.JsonReaderException: Unexpected character encountered while parsing value: {. Path ‘ReplyToAddress’, line 1, position 1015.
_ at Newtonsoft.Json.JsonTextReader.ReadStringValue(ReadType readType)_

The majority of our business endpoints are still on AmazonSQS v1.3.1. Looks like Service Control is triggering this known bug:

Looking at your Service Control SQS project for the 3.1.1 release you have not upgraded your SQS transport package to include the 4.1.1 patch:

Can you please update SC 3.1 to use 4.1.1 of the SQS transport?

Kind regards,