Note: the Request/Reply impl works very much like what is described on the linked RabbitMQ RPC article, i.e. the client creates an exclusive temporary queue before sending the message which the client can then choose to either synchronously block or poll for the response. I don’t think this should be combined/opinionated into a single blocking API for some of the same reasons they mention in “A note on RPC”.
Drazen Dotlic:
Request/Reply is also known as RPC, not sure what the problem is, +Demis Bellot is 100% right. In order to get the functionality +Wayne Brantley wants one only needs to build a tiny wrapper which calls from one service to the other ‘through’ MQ (we built one it’s like 10 lines of code), you can even pretend that you don’t know which mechanism is being used and in the future replace MQ with something else. Basically, it’s like an abstract bus between services.
As long as you host your services in the same AppDomain things work fine. When this is not the case, we’re seeing deadlocks (looks independent from the MQ implementation). This is really the only issue we’re having at the moment. ServiceStack completely and thoroughly covers all usual MQ scenarios, there’s not much to add.