Hi Asanka, Yes. How Qpid has done is, it gets selectors from subscribed subscribers for the queue and keep it as an attribute for queue. When a message comes for the queue, it evaluate all selectors and put message in. When messages are distributed to subscribers, selector is evaluated too.
Yes, this cannot be easily supported in our cluster architecture. What we can support easily is, 1. All subscribers for a queue has same selector 2. All subscribers for a durable topic subscription ID has same selector (I think this is the general usecase) 3. All subscriber for a topic in same node have same selector. Other combinations are not trivial. Another thought is,* what about giving all message slots to all nodes. they deliver to individually, and reference counting is in DB to see when individual message should be deleted*. But it does not align with current architecture. What we can give easily is a half-backed solution for selectors. Restricted to above 3 factors. Thanks On Thu, Dec 8, 2016 at 3:03 AM, Asanka Abeyweera <[email protected]> wrote: > A single queue can also have multiple subscribers with different selectors > and those subscribers can dynamically connect and disconnect. How are we > going to handle that? > > I think we need to have some kind of filtering mechanism in the delivery > side too involving slots. > > On Thu, Dec 8, 2016 at 8:55 AM, 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 >> >> > > > -- > Asanka Abeyweera > Senior Software Engineer > WSO2 Inc. > > Phone: +94 712228648 > Blog: a5anka.github.io > > <https://wso2.com/signature> > > _______________________________________________ > 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
