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
