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
