"Sticky" Message Handler configuration to a specific endpoint

[jeremydmiller]

This comes up often enough it's time to do something about it.

Let's say that there's a use case for the exact same message & message type to be handled separately and in parallel with separate message handlers. Wolverine can't do that today because it combines the handler calls on one chain ( a vestigal tail feature left over from the FubuTransportation roots)

Build some kind of syntax that allows for the handlers to be split between different endpoints & separate routing

[BrianVallelunga]

I'll add in our use case for reference. We have an Azure Service Bus Topic with multiple subscriptions. All messages sent to the topic are of the same type. However, each subscription on the topic has a filter on it and we want individual handlers for each subscription. Currently, all of our handlers are called, regardless of which subscription the message arrives from.

[jeremydmiller]

@BrianVallelunga I think this is likely to slide to Wolverine 2.3, but I'm hoping to get that out this coming week anyway. And thanks for the input!

[jeremydmiller]

@BrianVallelunga Unsurprisingly, I think I need to punt this until 2.4 in the next couple weeks. I've done some preliminary work and investigation so far.

[jeremydmiller]

Notes

• Create a one to many relationship between HandlerChain & Endpoint
• HandlerGraph should stop using the ImHashMap of message type to HandlerChain and message type to IMessageHandler
• Utilize the handler type & method name as part of the generated type name suffix for HandlerChain w/ sticky endpoint
• [StickyHandler("endpoint name")]
• HandlerGraph.Compile() needs to account for sticky endpoint to handler relationships
• HandlerGraph.HandlerFor() methods need to assert there's only one per message type, and have an overload that takes in Endpoint
• Add Endpoint argument to IExecutorFactory

[jeremydmiller]

@BrianVallelunga Here's the first tranche of work: https://github.com/JasperFx/wolverine/tree/sticky-handlers

More to come, but this will make it into 3.0

[BrianVallelunga]

Thanks for the update. I'm looking forward to trying this when 3.0 is out.