mqClient.Get - Does it handle listening for specific responses, or do we need to?

So far we’ve only worked with one way messages (publish and forget). The MQ server then does it’s thing, picks up the message, logs things, sends requests to other systems, and our UI polls looking for responses that were logged.

But now we need to implement kind of synchronous communication for some specific processes (logging in to state services, over an asynchronous flow). I don’t like the asynchronous nature of the system we are using, but there is nothing we can do about it (it’s what we’ve been given).

In most of your examples, you publish, then block on mqClient.Get<HelloResponse>. But what happens if there are hundreds of people publishing “Hello” messages? Is it guaranteed that the proper HelloResponse will be sent back to the original caller?

Code in the docs:

mqClient.Publish(new Hello { Name = "World" });

var responseMsg = mqClient.Get<HelloResponse>(QueueNames<HelloResponse>.In);
mqClient.Ack(responseMsg);
responseMsg.GetBody().Result //= Hello, World!

From http://docs.servicestack.net/messaging#messages-with-responses-are-published-to-the-response-inq

My hunch tells me that this blocking call could in fact receive anyone’s HelloResponse, and that Temp Queues are the answer to this. In this scenario we essentially have to keep track of the Temp Queue names ourselves, to track what message corresponds to what log.

Our needed flow going something like this

UI > WebAPI - UILoginRequest > Generate Temp Queue, send MqLogonRequest w/ Temp Queue, Block and wait > MQ host receives message, logs proprietary data about it in db, sends off to appropriate state service, returns immediate “Successfully Sent” or “Failed Sending” response > Web API unblocks and returns “Successfully Sent” or “Failed Sending” back to user.

I guess where I’m getting hung up is there is another step. After “sends off to appropriate state service” <-- this eventually returns the actual response from the state of Louisiana / Texas / Etc. So would it make sense to go ahead and allocate two temp queues? One for the “SimpleLoginResponse” that returns nearly immediately and one for the “FinalLoginResponse” which may return after 5-10 seconds? Or maybe there is a better way?

Additionally, in my MqLogonRequest handler, if it has a response type (say for instance, SimpleLoginResponse), will it automatically respond to the Temp Queue I originally passed in?

The pattern to send messages reply messages over MQ is to use a temp reply MQ, see docs for details:

http://docs.servicestack.net/messaging#responses-from-messages-with-replyto-are-published-to-that-address

I wouldn’t generate multiple temp queues for a single operation, if you need to monitor progress of a long operation either poll for the state transitions maintained in a database or listen to a topic for state transitions.

1 Like