Hi Shazni,
On Wed, Dec 7, 2016 at 4:09 AM, Shazni Nazeer <sha...@wso2.com> wrote: > Hi Hasitha, > > I have a question which is out of scope of your concern. But since it's > related to it I'm asking the question to know how that will be handled. > > When a selection criteria is not matched, how would the unmatched messages > be handled? Whether the messages are in queue or topic, would that end up > in Dead Letter Channel (DLC) or do you intend to keep it untouched wherever > it is. I had a requirement sometime back that when selection is not > matched, those unmatched messages should remain in the queue etc. Could > this be met in this implementation? > A good question. We can do two things. 1. If no subscriber's selector matches to the message we can inform the publisher "No routes to the message". That means there is no one in the subscriber side who is interested of this message. This is valid for topic scenarios. Broker will not even save the message. For queue scenarios I think it is not valid. 2. Thro the message to DLC. Users can manually schedule them once interested subscriber is there or whatever. In the implementation I suggest we can do both. > > On Wed, Dec 7, 2016 at 1:57 PM, 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 ? >> >> 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 <+94%2077%20777%209495> >> >> _______________________________________________ >> Architecture mailing list >> Architecture@wso2.org >> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture >> >> > > > -- > Shazni Nazeer > Associate Technical Lead | WSO2 > > Mob : +94 777737331 > LinkedIn : http://lk.linkedin.com/in/shazninazeer > Blog : http://shazninazeer.blogspot.com > > <http://wso2.com/signature> > Thanks -- *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
