rebus-org / Rebus.Async

:bus: Experimental async extensions for Rebus
https://mookid.dk/category/rebus
Other
13 stars 9 forks source link

Added PublishRequest which does the same thing that SendRequest, but … #12

Closed rsivanov closed 4 years ago

rsivanov commented 4 years ago

Added PublishRequest which does the same thing that SendRequest, but uses IBus.Publish instead of IBus.Send.

A scenario for which it is useful - we have multiple subscribers for Rebus.SignalR backplane listening for AddToGroup message for a particular connection. Only one host (where that connection lives) should reply to the message, but we don't know which one before the publishing of the message. So, we need to make a broadcast call (IBus.Publish) to all subscribed hosts.


Rebus is MIT-licensed. The code submitted in this pull request needs to carry the MIT license too. By leaving this text in, I hereby acknowledge that the code submitted in the pull request has the MIT license and can be merged with the Rebus codebase.

mookid8000 commented 4 years ago

Quick question though: What happens to additional replies, when they're received?

Are they silently ignored? Because I think they should be.....

rsivanov commented 4 years ago

Quick question though: What happens to additional replies, when they're received?

Are they silently ignored? Because I think they should be.....

Yes, they should be silently ignored. await PublishRequest returns when it receives the first reply (which should be the only one in case of the correct implementation). The worst that could happen with the current Rebus.Async implementation in case of receiving an additional reply - we would get a warning in the log: _log.Warn("Received message with message ID {messageId}, which was determined to be a reply to be handled as an inline request-reply reply (because of the {prefix} prefix), BUT the dictionary of task completion sources did NOT contain an entry for that ID", inReplyToMessageId, SpecialMessageIdPrefix); And this warning tells us, that our implementation of subscribers is incorrect

mookid8000 commented 4 years ago

And this warning tells us, that our implementation of subscribers is incorrect

but.... with the SignalR backplane implementation, wouldn't all subscribers reply back?

rsivanov commented 4 years ago

And this warning tells us, that our implementation of subscribers is incorrect

but.... with the SignalR backplane implementation, wouldn't all subscribers reply back?

No, just the one, that owns the connection. The others just ignore the message:

public Task Handle(AddToGroup<THub> message)        
{
    var connection = _hubLifetimeManager.Connections[message.ConnectionId];
    if (connection == null)
        return Task.CompletedTask;
    _hubLifetimeManager.AddGroupLocal(connection, message.GroupName);
    return _bus.Reply(new Ack<THub>(serverName: _hubLifetimeManager.ServerName));
}
mookid8000 commented 4 years ago

ah, ok!

I'll push a new version right away

mookid8000 commented 4 years ago

it's out in Rebus.Async 7.1.0, which is on NuGet.org now 🙂