Hi All, The current MB kernal architecture, complies to a model which takes each of the messages published through the store before delivering to the subscribers. Comparing against AMQP, MQTT QOS 2 is dependent on publisher side acknowledgments, where the publisher should be notified at a time where the message was delivered to its subscriber/s.
To address the use cases (QOS 0,2) we need to have a design which will allow broker to broker communication in a relational manner between the nodes for the following reasons, a) QOS 0 - This level of QOS should be a performance oriented level, taking it through the store will by default make the level QOS 1 and also will break the intention of using the level 0. b) QOS 2 - for publisher to be notified upon the delivery of the message to its subscribers we need to communicate among the brokers. We could use Hazelcast alternatively but IMO it could slow things down so better stick with a proper communication model. Based on the above facts we need to include a mechanism to allow broker to broker communication that would comply with both AMQP and MQTT. Should we consider introducing this mechanism for the forthcoming MB 3.0.0 release or should we stick with shipping MQTT having only QOS 1 and support levels 0,2 for the next release. WDYT ? Thanks, Pamod -- *Pamod Sylvester * *Senior Software Engineer * Integration Technologies Team, WSO2 Inc.; http://wso2.com email: [email protected] cell: +94 77 7779495
_______________________________________________ Architecture mailing list [email protected] https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
