Sounds like some pull requests are in order then. On Tue, Dec 27, 2011 at 7:55 AM, Jakub Berezanski <[email protected]>wrote:
> 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. > > -- 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.
