Hi Srinath, Currently, how we handle topics in cluster is, we create a queue with topicname+nodeID and duplicate messages+content per node (if that node has some subscriber to that topic). We reference count inside node when delivering messages and delete individual copy.
So yes, for topics we have to consider selectors at subscriber side, and do reference count based on interested subscribers only. Thanks On Wed, Dec 7, 2016 at 10:25 PM, Srinath Perera <[email protected]> wrote: > Hasitha, one topic can have multiple subscriptions. In that case, do we > duplicate the message content? How do we know when to delete the message > content? > > --Srinath > > On Wed, Dec 7, 2016 at 10:27 PM, Pamod Sylvester <[email protected]> wrote: > >> Based on the document in [1], It states the following, >> >> If the selector, or Topic values change for an subscription name already >> in use, *and there isnt an existing consumer on it*, the old >> subscription is effectively unsubscribed and a new one initiated. >> >> This clarifies the doubt i had. Which means we do not require to filter >> when delivering. If there's a re-subscription with a different selector we >> could simply un-subscribe form the existing and start a new session. >> >> [1] https://wiki.oasis-open.org/amqp-bindmap/JMSMapping/SubscriptionsV1 >> >> Thanks, >> Pamod >> >> On Wed, Dec 7, 2016 at 10:07 PM, Madhawa Gunasekara <[email protected]> >> wrote: >> >>> Hi All, >>> >>> AFAIK we can specify only one selector per consumer/subscriber, So we >>> can specify it using SQL92 conditional expression syntax. Therefore I think >>> this should work if we can use the Qpid selector logic. >>> Regarding the Shazni's question, In Queues, I believe we need to keep >>> remain unmatched messages in the queue/DLC since it wasn't delivered >>> correctly. We should deliver this message if someone interested later. WDYT >>> ?? >>> >>> Thanks, >>> Madhawa >>> >>> On Wed, Dec 7, 2016 at 9:24 PM, Pamod Sylvester <[email protected]> wrote: >>> >>>> I think it would be subjective, depends on what the application is >>>> intended to do. >>>> >>>> Let me try to give you an example (just to elaborate what i intended to >>>> say), >>>> >>>> let's say there's a topic which will receive events for sports. For the >>>> topic '*sports*' there could be different categories i.e football, >>>> cricket etc of messages which will be published. Each consumer listening to >>>> these events specify the type of sports they're interested in receiving >>>> through a selector condition i.e *sport=football. *Let's say the >>>> consumer who initially was interested in listening to football events >>>> wishes to receive the updates related to cricket i.e sport=*football* >>>> OR *cricket* which was received on topic *sports* while the consumer >>>> was offline. >>>> >>>> The point i intended to bring is, if selectors are intended to support >>>> a use case as above, we might need to consider accepting messages for a >>>> topic (without considering the filter/selector condition) and filter them >>>> only when its being delivered to a consumer. >>>> >>>> Anyhow +1 for further evaluating, also i agree this might be a rare use >>>> case and we don't need to implement it right a way . Just wanted to clarify >>>> at the initial stage so that our design supports it to be extended if it's >>>> required :) >>>> >>>> Thanks, >>>> Pamod >>>> >>>> On Wednesday, December 7, 2016, Hasitha Hiranya <[email protected]> >>>> wrote: >>>> >>>>> Hi Pamod, >>>>> >>>>> On Wed, Dec 7, 2016 at 8:39 AM, Pamod Sylvester <[email protected]> >>>>> 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 <[email protected]> >>>>>> wrote: >>>>>> >>>>>>> Hi Pamod, >>>>>>> >>>>>>> On Wed, Dec 7, 2016 at 3:27 AM, Pamod Sylvester <[email protected]> >>>>>>> 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 <[email protected] >>>>>>>> > 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 <077%20777%209495> >>>>>>>> >>>>>>> >>>>>>> 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 <077%20777%209495> >>>>>> >>>>>> >>>>> >>>>> >>>>> -- >>>>> *Hasitha Abeykoon* >>>>> Senior Software Engineer; WSO2, Inc.; http://wso2.com >>>>> *cell:* *+94 719363063* >>>>> *blog: **abeykoon.blogspot.com* <http://abeykoon.blogspot.com> >>>>> >>>>> >>>> _______________________________________________ >>>> Architecture mailing list >>>> [email protected] >>>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture >>>> >>>> >>> >>> >>> -- >>> *Madhawa Gunasekara* >>> Software Engineer >>> WSO2 Inc.; http://wso2.com >>> lean.enterprise.middleware >>> >>> mobile: +94 719411002 <+94+719411002> >>> blog: *http://madhawa-gunasekara.blogspot.com >>> <http://madhawa-gunasekara.blogspot.com>* >>> linkedin: *http://lk.linkedin.com/in/mgunasekara >>> <http://lk.linkedin.com/in/mgunasekara>* >>> >>> _______________________________________________ >>> Architecture mailing list >>> [email protected] >>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture >>> >>> >> >> >> -- >> *Pamod Sylvester * >> >> *WSO2 Inc.; http://wso2.com <http://wso2.com>* >> cell: +94 77 7779495 <+94%2077%20777%209495> >> >> _______________________________________________ >> Architecture mailing list >> [email protected] >> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture >> >> > > > -- > ============================ > 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 > > -- *Hasitha Abeykoon* Senior Software Engineer; WSO2, Inc.; http://wso2.com *cell:* *+94 719363063* *blog: **abeykoon.blogspot.com* <http://abeykoon.blogspot.com>
_______________________________________________ Architecture mailing list [email protected] https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
