The problem in itself is quite serious, as depending on the order of startup/shutdown of publishers and subscribers, either the publisher will fail to publish the event - RSB will raise an exception because no subscribers are present (and that is actually the _better_ outcome!), or the event will be published but will only be delivered to some subscribers (not all of them) - IMHO this second case is much worse, as the system now starts losing events (reliable messaging is why we implement a service bus in the first place!).
The second case will occur in the following scenario: ALB is started A1 is started B is started and subscribes to A1 via ALB A2 is started C is started and subscribes to A1 and A2 via ALB A2 publishes an event, which is received only by C; B will never know the event happened Mitigating this requires a careful orchestration of starting and stopping of services (when a new publisher node is added to the load balancing group, all subscribers need to resubscribe - without additional coding an application restart is required), which breaks service isolation and complicates an operation that should be simple and transparent to clients (adding a node to a LB cluster). My argument against shared storage is that in the setup with a separate load balancer service, the load balancer is the only thing that needs to be made reliable (e.g. by installing it on a failover cluster). Apart from that, the individual nodes do not share any single dependency. I was thinking on a solution along the following lines: when a new node registers itself in the load balancer, that node should receive the set of all current subscribers (so far same as whut wrote). The difference is that LB would not store the subscriptions itself, but instead could obtain them from existing nodes. Alternatively, LB could maintain a transient cache of subscriptions to reduce message traffic when a node is added to a group with many existing nodes. Using hardware load balanced Rhino Queues transport, without an explicit load balancer service, would certainly require a different solution. The problem, however, remains the same. I wonder, is anyone out there using load balanced RSB with publish/ subscribe? How did they solve this problem? On 14 Gru, 15:14, Corey Kaylor <[email protected]> wrote: > I don't think introducing a dependency on the load balancer for the > subscription storage is the right place for this. Reasoning is that rhino > queues is load balanced via hardware. It is probably better to create a > shared storage between them, either SQL, Raven, etc. > > > > On Wed, Dec 14, 2011 at 6:44 AM, whut <[email protected]> wrote: > > Lets have loadbalancer ALB with two servers A1 and A2. If we then > > start another server B, that subscribes to event from A, both A1 and > > A2 will have info about that in their subscribers subqueues. But if we > > then add another A server, lets call it A3, it will not know about > > such subscriptions and will have empty subscribers subqueue. > > > I believe that A3 should be able to publish events even if it started > > long after B. ALB should store all subscriptions, and sent them to A3 > > when it starts. > > > What you think about it? > > > -- > > You received this message because you are subscribed to the Google Groups > > "Rhino Tools Dev" group. > > To post to this group, send email to [email protected]. > > To unsubscribe from this group, send email to > > [email protected]. > > For more options, visit this group at > >http://groups.google.com/group/rhino-tools-dev?hl=en. -- You received this message because you are subscribed to the Google Groups "Rhino Tools Dev" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/rhino-tools-dev?hl=en.
