Asynchronous request-response with correlation

[sonst...@googlemail.com]

I think the built-in request-response in MassTransit is synchronous.
I want to do an asynchronous request-response, i.e., receive the response as an usual message, even if the requester crashes after sending the request, but before receiving the response.

I tried it like that and hoped, that RespondAsync() would automatically set the correlation ID from the request in the response, but it does not. Is there any built-in support for asynchronous request-response or do I really have to set the correlation ID in the respond by hand? Is RespondAsync() appropriate for my use case at all?

class MyRequest : CorrelatedBy<Guid>
{
 public Guid CorrelationId {get; set;}
}

// in the requester
var myCorrId = Guid.NewGuid();
var request = new MyRequest()
{
  CorrelationId = myCorrId
};

sendEndpoint.Send(request);

...
public async Task Consume(ConsumeContext<MyResponse> context)
{
   Console.Out.WriteLineAsync("Received message with correlation id: " + context.CorrelationId);
}

// on the other side
public async Task Consume(ConsumeContext<MyRequest> context)
{
   var response = new MyResponse();
   await context.RespondAsync(response);
}

[Alexey Zimarev]

To be honest, I am not sure why do you think that request/response is synchronous. By definition everything that is done using messages is asynchronous. Request/response just waits to get a reply back as a usual message.

[Alexey Zimarev]

Here is what Respond does. As you can see, it just calls RepondAsync. How your MyReponse looks like? Does it have the correlation id property as well?

        public void Respond<T>(T message)

            where T : class

        {

            var task = RespondAsync(message);

            _receiveContext.AddPendingTask(task);

        }

[Chris Patterson]

Request/Response does not use CorrelationId, it uses RequestId - which is a separate header.

--
You received this message because you are subscribed to the Google Groups "masstransit-discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email to masstransit-discuss+unsub...@googlegroups.com.
To post to this group, send email to masstransit-discuss@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/masstransit-discuss/41c92418-89cf-4aed-9122-6f4444803642%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Alexey Zimarev]

But if one want to use correlation id, it should be enough just to have this property available in the reply message, the context send pipeline should set the correct value, right?

[Chris Patterson]

CorrelationId is not typically copied, it is, however, used to set the InitiatorId on the message to provide correlation. ConversationId is the same across the message flow, however.

ConversationId = Once set, it carried through all messages in that flow.

CorrelationId = set by the sender, or by conventions

InitiatorId = assigned the correlationId of the consumed message (which initiated the message being sent now)

RequestId = set when a request is sent, and returned by the response with the same value

--
You received this message because you are subscribed to the Google Groups "masstransit-discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email to masstransit-discuss+unsub...@googlegroups.com.
To post to this group, send email to masstransit-discuss@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/masstransit-discuss/963E0AC3-8D99-47B7-B533-7420754D2D35%40gmail.com.

[Alexey Zimarev]

Ok, so I mean this one.

[sonst...@googlemail.com]

Request/response just waits to get a reply back as a usual message.

Yes, it waits synchronously or asynchronously. However, asynchronous request/response does not wait, but just receives the response in an usual consumer.
That means, if the requester fails after sending the response and is restarted, it will still receive the response, because the response waited in the queue.
With synchronous request/response as implemented by the MessageRequestClient, the response could not be handled anymore in such a scenario
and would be moved to the skipped queue, I suppose.
 

I fear none of the existing IDs does exactly what I want.
I want to set a custom ID when sending a request. I store this ID together with some context data in a persistent store.
When receiving the response, the custom ID should be available in the response handler, so that I can load the data from the persistent store.

I could set the CorrelationId explicitly when making the request and InitiatorId when handling the response.
I fear that it could cause problems in some situations when there was already an CorrelationId (e. g. in a saga) when making the request,
so that it would be overriden.

[sonst...@googlemail.com]

Is it possible to set headers for individual messages when sending from IBus?

[Chris Patterson]

You want to use a saga, based upon what you described. Rather than a simple request and response. Sagas have an independent lifecycle driven by events, which sound more suited to your problem. 

__
Chris Patterson

On Sun, Mar 26, 2017 at 7:36 AM -0700, "sonstiges28 via masstransit-discuss" <masstrans...@googlegroups.com> wrote:

Is it possible to set headers for individual messages when sending from IBus?

--

You received this message because you are subscribed to the Google Groups "masstransit-discuss" group.

To unsubscribe from this group and stop receiving emails from it, send an email to masstransit-dis...@googlegroups.com.
To post to this group, send email to masstrans...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/masstransit-discuss/364c1b94-ac7f-4fe5-bcf5-83c7b23d03d5%40googlegroups.com.

[sonst...@googlemail.com]

> You want to use a saga, based upon what you described. Rather than a
> simple request and response. Sagas have an independent lifecycle driven
> by events, which sound more suited to your problem.

A saga was my first idea, too.

I think for starting a saga instance you have to receive a message, though.
What if I do not want to send the request from a handler, but because a
user pressed a button, so that I only have IBus and not received any
message before?