Hi, According to the discussion we had with Srinath there were some changes of the above proposal.
1. Instead of having queuesCount X nodeCount number of slots, we keep infinite number of slots with a limited number of capacity. The capacity of the slot is configurable. 2. When a message comes to a queue we create a slot and put it in the slot until the slot exceeds its maximum threshold capacity. When a slot exceeds its capacity we create a new slot and put the messages there. 3. When a subscriber subscribes from a node, we assign a slot to that node from free slot pool. 4. If a subscriber disappeared from a node, that subscriber's slot can be assigned to someone else. No need to copy messages to somewhere else. In this manner messages are not needed to be copied around. Message will be write only once and read once. Thank you, Sajini. On Fri, Jul 25, 2014 at 8:56 AM, Srinath Perera <[email protected]> wrote: > Challenge is we do not know how many subscriptions the topic would > receive. > > If we write message to multiple slots .. and only one subscription came, > we are in trouble. I am inclined to say we write to one slot (slots are in > Cassandra and so slot can be big) and split them only when there are > multiple subscriptions. > > We need to discuss more. Can we chat f2f with Shammi and Hasitha and > others. Key is to minimize the chance of having to do slot merges etc. > > --Srinath > > > On Thu, Jul 24, 2014 at 10:09 PM, Sajini De Silva <[email protected]> wrote: > >> Hi Srinath, >> >> While reading this the question came in to my mind was how this addresses >> the problem we were trying to solve using high and low water mark levels. >> So I had an offline discussion with Shammi and came up with the following >> solution. >> >> 1. When we receive messages, if there is no subscription, rather than >> taking the slot and writing all the messages to that slot create multiple >> number of slots which have messages up to HWM level. >> 2. If a queue has subscriptions from multiple nodes, then we will >> give it several slots, assign those slots to corresponding nodes. When >> distributing messages to those slots copy only messages up to HWM level. >> >> What do you think? >> >> Thank you, >> >> Sajini. >> >> >> >> >> On Thu, Jul 24, 2014 at 3:09 PM, Srinath Perera <[email protected]> wrote: >> >>> Currently we use Global queue to handle the scenario where we receive >>> messages for a queue that does not have any subscriptions. However, due to >>> this large latency is added and message need to copied around lot. >>> >>> Shammi and myself were discussing and look like it is possible to remove >>> it completely. Following is the proposal. >>> >>> >>> 1. We define a concept called slots where we can store messages in >>> Cassandra. Each slot map to a row in Cassandra or a RDBMS table. There >>> are >>> queuesCount X nodeCount slots in the system. >>> 2. Only one node own a slot at a time. When the node own the slot, >>> it reads messages from the slot and send to subscribers. (This is what >>> QueueDeliveryWorker do). This slot assignment we can manage via hazecast. >>> 3. When we receive messages, if there is no subscription, we take a >>> slot and write messages to that slot. When there is subscription to that >>> queue, we assign the slot to associated node for subscription. >>> 4. If a queue has subscriptions from multiple nodes, then we will >>> give it several slots, assign those slots to corresponding nodes.The we >>> distribute messages to those slots. >>> 5. With this model, each message will be only written once and read >>> once mostly. >>> 6. There will be some edge cases (e.g. when a node run out >>> subscriptions etc) where we might need to merge or split messages in >>> slots. >>> These we have to do carefully, but since those are rare, the overhead >>> added >>> is minimal. >>> 7. Each query delivery worker would need to read a slot for each >>> queue. So we need to keep a thread pool and manage reading. >>> >>> This should also reduce number of Cassandra calls by about 50%. >>> >>> WDYT? >>> >>> --Srinath >>> >>> -- >>> ============================ >>> Srinath Perera, Ph.D. >>> http://people.apache.org/~hemapani/ >>> http://srinathsview.blogspot.com/ >>> >>> _______________________________________________ >>> Architecture mailing list >>> [email protected] >>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture >>> >>> >> >> >> -- >> Sajini De SIlva >> Software Engineer; WSO2 Inc.; http://wso2.com , >> Email: [email protected] >> Blog: http://sajinid.blogspot.com/ >> Git hub profile: https://github.com/sajinidesilva >> >> > > > -- > ============================ > Director, Research, WSO2 Inc. > Visiting Faculty, University of Moratuwa > Member, Apache Software Foundation > Research Scientist, Lanka Software Foundation > Blog: http://srinathsview.blogspot.com twitter:@srinath_perera > Site: http://people.apache.org/~hemapani/ > Photos: http://www.flickr.com/photos/hemapani/ > Phone: 0772360902 > -- Sajini De SIlva Software Engineer; WSO2 Inc.; http://wso2.com , Email: [email protected] Blog: http://sajinid.blogspot.com/ Git hub profile: https://github.com/sajinidesilva
_______________________________________________ Architecture mailing list [email protected] https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
