1

For long-running message-based requests, we can set the visibility timeout at the queue level, but there doesn't appear to be a way to override it at the message level. I'd like to be able to extend the time for long-running operations without just setting a queue-wide extra long timeout. The underlying SQS service provides the ChangeMessageVisibility function but it's not exposed. From what I can tell, RedisMQ doesn't support the concept at all.

  1. Is there effectively ever a timeout and retry for RedisMQ?
  2. Is it possible to expose the ability to extend visibility time from within a service? A long-running operation could then call it periodically to get enough time.
JoshMc
  • 10,239
  • 2
  • 19
  • 38
Arian Kulp
  • 831
  • 8
  • 31

1 Answers1

1

Redis MQ is not related to Amazon SQS or ServiceStack's Amazon SQS MQ other than they're different concrete implementations of ServiceStack's Messaging APIs but a ServiceStack AppHost can only have 1 IMessageService registered so I don't understand how using Redis MQ is relevant to your use of Amazon SQS?

Redis MQ is built on top of Redis's List and Pub/Sub primitives and doesn't contain any such MQ customizations.

If you're just referring to Amazon SQS MQ then there's a RegisterHandler overload that lets you specify the visibilityTimeoutSeconds per message Type so you could have long-running requests executed with a different Request DTO Type which would be my recommendation to keep them isolated. ServiceStack's Auto Mapping makes it easy to convert between Request DTOs with the same schema, e.g:

public object Any(MyRequest request) { ... }
public object Any(LongRunning request) => Any(request.ConvertTo<MyRequest>());

The SqsMqServer does have RequestFilter and ResponseFilter you can use to inspect the IMessage<T> that's returned by ServiceStack MQ which can be used to change the metadata sent in the SQS Message but not any of its custom message-level properties.

To enable fine-grained access to SQS I've added the following filters to SqsMqServer, SqsMqMessageFactory and SqsMqClient in this commit which will allow you to intercept and customize the requests going to and coming from Amazon SQS:

Action<SendMessageRequest,IMessage> SendMessageRequestFilter { get; set; }
Action<ReceiveMessageRequest> ReceiveMessageRequestFilter { get; set; }
Action<Amazon.SQS.Model.Message, IMessage> ReceiveMessageResponseFilter { get; set; }
Action<DeleteMessageRequest> DeleteMessageRequestFilter { get; set; }
Action<ChangeMessageVisibilityRequest> ChangeMessageVisibilityRequestFilter { get; set; }

This change is available from v5.4.1 that's now available on MyGet.

mythz
  • 141,670
  • 29
  • 246
  • 390
  • I asked about both services since I realize that any such SS feature would need to work across providers. We use RedisMQ and SQS depending on environment. It sounds like the above is still at the message type level rather than in the context of each request, or at least at the point of interception. I'd like to set a reasonable visibility across the board for a given message type, but during processing extend it if I'm still doing work. Right when the message is received I might not know it will be long to process (due to other dependencies) so extending it during processing would be nice. – Arian Kulp Feb 21 '19 at 08:16