The following is being called in a service (these two lines). With the InMemoryTransientMessageService the call is blocked until the publish returns. Is this the expected behaviour? I was assuming it would spawn a thread and process it in the background?
return new PageResult(Pages.GetPage("templates/done"))
Nevermind I just read this thread. https://forums.servicestack.net/t/inmemorymq-doesnt-return-until-after-long-running-code-completed/3522
It would be nice if the in memory provider would work like the others in this sense as it would provide an easy way to manage background work instead of having to install hangfire or something similar which is overkill in many easy cases.
Don't waste your feature wishlist in the forums, add them to User Voice so it doesn't get lost, their interest can be measured and you can get notifications on updates from both us and discussion about the feature from other community members.
Thanks. I'm still undecided if it is worth the feature request. A sql mq provider like hangfire has might be a better feature request and I'm going to think about it.
As an aside I'm going to use hangfire and its sql server job storage for this as performance is decent enough for simple things and the project already has it. I integrated it with service stack with a class that executes the requests. It seems to work well enough although I suspect there is a better way.
BackgroundJob.Enqueue<ServiceStackExector>(x => x.Execute<RequestClass>(request));
public class ServiceStackExector
public void Execute<T>(T request)
Update for anyone else this might help. I ended up writing a backgroundjob helper:
public static class ServiceStackJob
public static string Enqueue<T>(T request )
return BackgroundJob.Enqueue<ServiceStackExector>(x => x.Execute<T>(request));
Now one can do, the job will be managed via hangfire (like mq) and will execute the request.