ServiceControl 3.3.0 - Minor release available

Hi everybody,

We’ve just released ServiceControl 3.3.0.

This version of ServiceControl introduces more transport options as well as a few bug fixes and improvements.

The transport options available for ServiceControl and Monitoring instances are now aligned and allows Azure Service Bus and RabbitMQ users to choose from the following options:

Bug fixes

  • Monitoring Instances
    • #156 - SQSTransport does not support QueueNamePrefix
    • #105 - RabbitMQ transport should disable unused timeout manager queues
  • ServiceControl Instances
    • #1448 - Result paging is broken when Service Control secured via a reverse proxy
    • #1477 - Fix concurrency issues in retry manager
    • #1374 - ServiceControl Management Utility dropdown menus are misaligned

Should you upgrade immediately

You should upgrade during the next available maintenance window.

Where to get it

You can download this release from our website.

With thanks,

The team in Particular

Hi Guys,

This patch release (and the subsequent two up to 3.3.2) do not fix the SQS prefix issue for service control monitoring.

Here is a snapshot of my local monitoring config:

You can see my configured queue prefix is “lpi-dev-sqspoc-670-” but when the monitoring service is restarted and I start up one of the business end points with the monitoring plug in installed I still get the following error in the monitoring service logs (GRM-ActivityStream-DataMigration-Host is the logical endpoint name of the business service):

2018-11-21 17:14:22.2167|18|Error|ServiceControl.Transports.AmazonSQS.QueueLengthProvider|Obtaining an approximate number of messages failed for ‘GRM-ActivityStream-DataMigration-Host’
Amazon.SQS.Model.QueueDoesNotExistException: The specified queue does not exist for this wsdl version. —> Amazon.Runtime.Internal.HttpErrorResponseException: The remote server returned an error: (400) Bad Request. —> System.Net.WebException: The remote server returned an error: (400) Bad Request.
at System.Net.HttpWebRequest.EndGetResponse(IAsyncResult asyncResult)
at System.Threading.Tasks.TaskFactory1.FromAsyncCoreLogic(IAsyncResult iar, Func2 endFunction, Action1 endAction, Task1 promise, Boolean requiresSynchronization)

I can see the fix in the ServicedControl.Montoring solution in GutHub. Perhaps this is a bundling/packaging issue? Or is there some other aspect of configuration I am missing?

Kind regards,


Did you reconfigure the queue prefix on an existing instance or reinstall with the queue name prefix?


Hi Daniel,

I installed a new instance as the previous one was renamed to include the queue prefix in the service name.

Hi Edward,



Nothing in the logs on my side.

Maybe it is best if we get on a call so that we can trouble shoot that issue better. Shoot me an email to daniel dot marbach at particular dot net and I’ll try to find a slot that works for both of us. Please add the timezone you are in as an additional info.

Sorry that you have to go through this