Are there any plans to add an Async option for PublishMessage for SQS?
No, all messaging is inherently one-way/async already i.e. you’re only queuing the message not executing it, the bottleneck is not in queuing the message, it’s executing it.
For info on any future features look to UserVoice, unless it’s been requested it’s not being considered.
Except that there could be a delay in queuing the message if for example SQS is taking awhile, etc. SQS itself has Async options so I’m not sure why it’s acceptable there, but not here.
In any event, I’ll go ahead and add it to UserVoice.
Thanks
If your MQ broker has load issues async isn’t going to help, client async doesn’t reduce server utilization. Your MQ broker should be the last piece of critical infrastructure that should be overloaded - which would be hard to do as they don’t execute the message, they only deliver it, and their built purpose-specific for the task.
Network issues/delays, dns issues, etc? I mean, then why have any async methods on external services? In my experience, IO is almost ALWAYS the place you want async.
I see someone else asked about this as well.
But that’s ok, I understand this is probably a very low priority for you in the grand scheme of things. I was just trying to cover the case when something was wrong at this point to not block the whole function, since the function itself is Async Task, which this sort of defeats. But I’ll get by. Thanks.
Async is definitely not going to prevent any network issues. There are no DNS requests when publishing messages, only once upon connection if using a domain name.
Because they help with server thread utilization, how a server is called (i.e. client sync/async) is completely transparent to the server.
So I’m still not understanding this part: If SQS itself has an async method to queue a message, then why would it not make sense to be able to even use that method from ServiceStack?
It’s very low priority, there’s never been a technical reported issue that async APIs would resolve, but primarily it would be disruptive to the existing very stable IMessage APIs that all MQ providers would need to implement.
Other than it being very disruptive, given it’s never been requested, means there’s no priority for this feature.
Ok, that makes sense. Thanks