search

SzymonPobiega / NServiceBus.Router

Cross-transport, cross-site and possibly cross-cloud router component for NServiceBus
MIT License
5 stars 10 forks source link

Sample project throws exception "NServiceBus.Router.UnforwardableMessageException" #18

Closed robj-applied closed 5 years ago

robj-applied commented 5 years ago

Hi, been trying to setup mixed transports using this project. My Endpoint/Routing instances are

When I run them all I get the exception:

Interface Moving poison message to the error queue NServiceBus.Router.UnforwardableMessageException: No route for destination DirectEvents.WebApp

(Where DirectEvents.WebApp is the RabbitMQ Endpoint)

To see where I was going wrong I downloaded and ran the sample solution from here - https://docs.particular.net/samples/router/mixed-transports/

And when I run the server/router/client here I run into basically the same issue:

Interface Moving poison message to the error queue NServiceBus.Router.UnforwardableMessageException: No route for destination Samples.Router.MixedTransports.Server

I'm using:

Happy to post a sample solution if that would help - but maybe the sample project download on the Particular page might be enough as they produce the same error?

If it helps, I can send commands from the Rabbit endpoint, through the router to MSMQ endpoint absolutely fine. Just the event pub/sub is not working, as with the sample project.

Thanks in advance.

sdargaud commented 5 years ago

Hi, I ran into the same issue using the sample named "sql-switch" if that matters.

robj-applied commented 5 years ago

I believe I've found the issue:

staticRouting.AddForwardRoute("RabbitMQ", "MSMQ");

Should be:

staticRouting.AddForwardRoute("RabbitMQ", "MSMQ");
staticRouting.AddForwardRoute("MSMQ", "RabbitMQ");

Everything seems to work now. Presumably it couldn't find a way of letting the Rabbit service know that there was a subscription because there was no route through from MSMQ to Rabbit.

It'd be helpful if somebody could clarify if this is indeed the "fix".

SzymonPobiega commented 5 years ago

@robj-applied thanks for providing the fix. I'll update the sample. Sorry for the problem. @sdargaud the problem with "sql-switch" was in the Router itself. I've released a new version (3.5.1) that fixes it. I've run that sample and works fine.

SzymonPobiega commented 5 years ago

@robj-applied I am a bit confused. I've checked the sample and it seem to work just fine and the code contains the correct MSMQ -> RabbitMQ forwarding: https://github.com/Particular/docs.particular.net/blob/master/samples/router/mixed-transports/Router_3/Router/Program.cs#L26

robj-applied commented 5 years ago

@SzymonPobiega The link you've given there does indeed have the MSMQ > RabbitMq routing. The sample I downloaded (on the day I raised this issue) had RabbitMQ > MSMQ. So something isn't right there - perhaps the download on the Particular site is an older version?

Anyway, I had to make sure it had both before I could get it to work. And that makes sense doesn't it? Because the MSMQ end needs to subscribe to the Rabbit end (MSMQ > RabbitMq) and the Rabbit end needs to be able to publish to the MSMQ end (RabbitMq > MSMQ).

Grateful for the response!

SzymonPobiega commented 5 years ago

@robj-applied the way the Router is build, the routing table needs to be configured only for send and subscribe messages. It does not have to be configured for the published events or replies. The rationale for this is that the endpoint that publishes events or replies to commands should not be concerned if the subscriber or sender of a command is behind a router or not.

The way this is implemented is that a command carries (in the correlation ID header) a trace of the routers it passed through so that the reply can travel the same router in the opposite direction. With the subscriptions the router remembers who is subscribed so when the published messages comes in, it knows where to forward it by looking at the subscriptions.

The end result is that you only need to configure the routing (of which the simplest form is just plain forwarding used in this sample) for the commands and subscriptions. It does not hurt, though, to configure the forwarding both ways just in case at some point somebody decides to send messages in the opposite direction.

robj-applied commented 5 years ago

Ok thanks @SzymonPobiega, that makes sense. Looks like the sample version has been updated too so it's the right way round. I'll close - appreciate the responses!