Hi Pamod, I think it would be a good idea if we can write a sound article on MQTT usage, design and performance of MQTT on MB 3, highlighting what we additionally get compared to the others (scalability by adding brokers, configurable stores etc) and others.
We can put it out parallel to MB release and point that document if some customer is interested on MQTT provided by MB 3.0.0. For MQTT there might be a good interest out there. WDYT? Thanks On Wed, May 13, 2015 at 4:35 AM, Pamod Sylvester <[email protected]> wrote: > Hi All, > > The following changes were made to the MQTT architecture in order to > achieve a more flexible/extensible design. The details are as follows, > > *Design * > > The goal is to allow flexibility to define distribution/delivery > semantics, once the protocol specific logic is executed the message > handling could be defined through a connector. The connector could be > defined through implementing MQTTConnector interface. We could allow the > user to define the connector in the broker.xml which will look something > like the following, > > > <connector>org.wso2.andes.mqtt.connectors.DistributedStoreConnector</connector> > > This way it will allow customization of delivery/distribution semantics if > required i.e message filtering, different retry logic. Also the idea is to > set the phase to implement the broker-broker support which will be > introduced in future MB versions. > > *Interface and Methods * > > The MQTTConnector interface would have the following methods which should > be implemented by the inheriting class , > > > * addMessage *- When a message is published > this should be called > *messageAck* - Triggers when an > acknowledgment is received > *addSubscriber *- Called when a subscriber joins > *removeSubscriber * - Calls when a subscriber with > clean session set to false (durable) sends un-subscription request > *disconnectSubscriber* - Triggers when a subscription > disconnects > * removePublisher * - Triggers when a publisher > disconnects > > > *Implemented Connectors* > > *DistributedStoreConnector* - This should be the default > connector that will interface with the andes core. > *InMemoryConnector * - This will be supported only > for stand-alone deployments, also this will support only QoS level 0 since > other level of > QoS will > require interaction with message store. This connector will allow bypassing > the message store and the messages will be delivered > for its best > performance effort in comparison. > > > *Performance Comparison * > > A performance comparison was done to compare between the two connectors. > The following are the results in summary. > > *Number of Messages (1KB)**Highest TPS **Lowest TPS **Average TPS > **DistributedStoreConnector > - Default h2 as db*100,00022008002000*InMemoryConnector* > 100,00028721225.22200 > > Note : the comparison was done having the MB executed in stand-alone mode. > The messages were sent/received with QoS level 0. > > Please do comment if i've missed out on anything. WDYT ? > > Thanks, > Pamod > > -- > Pamod Sylvester > WSO2 Inc.; http://wso2.com > cell: +94 77 7779495 > > _______________________________________________ > 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
