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?
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.
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?