Pamod, as per our chat.

1. Lets only support this scenario, not create a higher level concept that
we do not understand well. For MQTT case, we can automatically do this ( if
message published as QOS0, and all subscriptions are QOS0, then skip
writing to the disk).

2. Too late to do the change now, lets do it for the next release.

--Srinath

On Thu, May 14, 2015 at 9:05 AM, Pamod Sylvester <[email protected]> wrote:

> Hi Hasitha,
>
> +1 Srinath too suggested on same.
>
> Thanks,
> Pamod
>
> On Thu, May 14, 2015 at 2:26 AM, Hasitha Hiranya <[email protected]>
> wrote:
>
>> 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
>>
>>
>
>
> --
> *Pamod Sylvester *
>
> *WSO2 Inc.; http://wso2.com <http://wso2.com>*
> cell: +94 77 7779495
>
> _______________________________________________
> Architecture mailing list
> [email protected]
> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
>
>


-- 
============================
Blog: http://srinathsview.blogspot.com twitter:@srinath_perera
Site: http://people.apache.org/~hemapani/
Photos: http://www.flickr.com/photos/hemapani/
Phone: 0772360902
_______________________________________________
Architecture mailing list
[email protected]
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture

Reply via email to