Hi Srinath/All, Just a couple of questions that popped into mind about option 2, if we are going with option 1 this wont really matter.
1. If the topics are durable the node will not be able to delete the messages if even one of the clients that have a subscriptions have disconnected right?. 2. And What happens if a node drops out? Are the subscriptions of a particular client only kept in a single node or is that also replicated in several nodes according to some replication factor? Regards, Pulasthi On Fri, Oct 24, 2014 at 8:00 AM, Srinath Perera <[email protected]> wrote: > Hi Paul, All, > > Let me explain the problem > > AMQP model has queues that users can consume. Queue model and Pub/sub etc > are done via exchanges. Basically, exchange may place message in one or > more queues, and consumers for queues may get them. > > Queues can be durable - clients give a name to subscription, and messages > will be saved for him if he has disconnected. > > Queues can be persistent - written to disk > > > > MB nodes talk to each other via queue, MB queues are always persistant. > > 1. Queues matches this model well, that is done > 2. For topics with durable subscriptions, we replicate both metdata and > content to for each subscription. This has to be done as different people > may consume those queues in different speeds. (Doing distributed reference > counting to decide when to delete content is too complicated yet IMO) > 3. there are several ways to implement normal topics > > Option 1: handle it same as durable subscription, but delete the queue > when subscription dropped. (Most simple Implementation, but if topic has > 100 subscribers, 100 copies are made) > > Option2: replicate metadata and content once for each node, then node > deliver messages to each subscription on that node and delete content. > (Maximum number of copies made per messages as number of nodes). This needs > us to maintain complete separate path for topics. > > Option 3: When topic publish is made, push the message to all node with > subscriptions via a network connection. This will be much faster, but need > to be implemented from scratch. Something similar we need to implement for > MQTT QOS2 eventually. > > Current code use option 2, but does not replicate content. So significant > amount of fixes needs to be made to keep the code. > > My question is, what option should we go with for 3.0.0? I am inclined to > do option #1 as that is simplest, and add option 3 in 3.1.0. > > WDYT? > > --Srinath > > -- > ============================ > Blog: http://srinathsview.blogspot.com twitter:@srinath_perera > Site: http://people.apache.org/~hemapani/ > Photos: http://www.flickr.com/photos/hemapani/ > Phone: 0772360902 > > _______________________________________________ > Architecture mailing list > [email protected] > https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture > > -- -- Pulasthi Supun Software Engineer; WSO2 Inc.; http://wso2.com, Email: [email protected] Mobile: +94 (71) 9258281 Blog : http://pulasthisupun.blogspot.com/ Git hub profile: https://github.com/pulasthi
_______________________________________________ Architecture mailing list [email protected] https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
