Hi Pamod, On Wed, Dec 7, 2016 at 8:39 AM, Pamod Sylvester <pa...@wso2.com> wrote:
> Hi Hasitha, > > Just to understand. So in AMQP model does it state that an offline durable > subscriber cannot re subscribe with a different selector query ? > I think so. But let's verify (might be broker dependent) > > if it's the case I agree we might be able to partion at the publishing > state. Where the model would be cleaner and less complex. If it's not the > case IMO still I don't see how the condition could be invalid. > Let us look at the practical case first and try to implement. We can state it as a limitation if we have to. Will not be a matter, as in practical world applications would not resubscribe with different selectors to middleware. WDYT? > > My point it if it's valid we might have to further filter before > delivering to the subscriptions. > > Thanks, > Pamod > > On Wednesday, December 7, 2016, Hasitha Hiranya <hasit...@wso2.com> wrote: > >> Hi Pamod, >> >> On Wed, Dec 7, 2016 at 3:27 AM, Pamod Sylvester <pa...@wso2.com> wrote: >> >>> Hi Hasitha, >>> >>> An aspect i was thinking is. let's say there's a durable subscription >>> having the selector query/condition as '*groupID > 12*' , once the >>> messages are being published the durable subscription goes offline and >>> reconnects with a different selector query i.e '*groupID > 100*' if >>> this case is valid, how will we address this condition ? >>> >>> >> This condition is invalid. If you look at AMQP model (forget about all >> clustering stories), even there we cannot handle this situation. So >> invalid. >> >> >>> Thanks, >>> Pamod >>> >>> On Wed, Dec 7, 2016 at 11:15 AM, Hasitha Hiranya <hasit...@wso2.com> >>> wrote: >>> >>>> Hi, >>>> >>>> I have following suggestion on how to implement message selectors on MB >>>> >>>> [image: Inline image 1] >>>> >>>> >>>> - With cluster notification upon subscription we send selector >>>> information as well. >>>> - So each node knows all subscribers with their selector info >>>> - When a message is published, when storing (or cloning and storing >>>> for durable topic subscribers), we store only if selector matches >>>> - This is possible if we expose selector logic of Qpid to andes >>>> core using an interface. >>>> - Then there will be no changes in delivery side. Even for durable >>>> topic subscribers this will work. >>>> >>>> >>>> WDYT? Please share your ideas. >>>> >>>> Thanks >>>> Hasitha >>>> >>>> -- >>>> *Hasitha Abeykoon* >>>> Senior Software Engineer; WSO2, Inc.; http://wso2.com >>>> *cell:* *+94 719363063* >>>> *blog: **abeykoon.blogspot.com* <http://abeykoon.blogspot.com> >>>> >>>> >>> >>> >>> -- >>> *Pamod Sylvester * >>> >>> *WSO2 Inc.; http://wso2.com <http://wso2.com>* >>> cell: +94 77 7779495 >>> >> >> Thanks >> >> -- >> *Hasitha Abeykoon* >> Senior Software Engineer; WSO2, Inc.; http://wso2.com >> *cell:* *+94 719363063* >> *blog: **abeykoon.blogspot.com* <http://abeykoon.blogspot.com> >> >> > > -- > *Pamod Sylvester * > > *WSO2 Inc.; http://wso2.com <http://wso2.com>* > cell: +94 77 7779495 > > -- *Hasitha Abeykoon* Senior Software Engineer; WSO2, Inc.; http://wso2.com *cell:* *+94 719363063* *blog: **abeykoon.blogspot.com* <http://abeykoon.blogspot.com>
_______________________________________________ Architecture mailing list Architecture@wso2.org https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
