I'm actually a fan of Udi's approach and isolating consumers / sagas into individual endpoints. It wouldn't be too hard to manage if using something like Topshelf that can spool up an appdomain for each folder under a /Services folder where an assembly implements something like IBootStrapper. I had plans to incorporate a hosting option that uses Topshelf for this reason.
By having all your messages in separate endpoints they will no longer compete with each other for things like this and will typically perform pretty well on one thread. Also when a subscriber goes down, it doesn't affect the SLA of other things trying to send messages to other subscribers unrelated to the one that went down. One message handler that takes 30 seconds doesn't affect another that is much faster and receives more messages. It also allows you to scale individual components that need to scale, not the entire thing just because a couple don't perform well. Also once you've deployed this way performance counters could paint a very interesting picture of what's going on with your business, not just what's going on with EndpointA that handles 200 types of messages. -- You received this message because you are subscribed to the Google Groups "Rhino Tools Dev" group. To post to this group, send email to rhino-tools-dev@googlegroups.com. To unsubscribe from this group, send email to rhino-tools-dev+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/rhino-tools-dev?hl=en.
