The issue was due to the storage queue name not being specified on acked message hence the messages were not further processed for deletion, the issue was fixed.
On Sun, Nov 16, 2014 at 4:55 PM, Pamod Sylvester <[email protected]> wrote: > Hi All, > > While testing MQTT with large message counts Akalanka noticed that despite > the number of messages being sent only 65536 messages were delivered to > the subscribers. Also it was noted that worker thread responsible for > delivering the messages complaining on flusher growing. Subscriber > reconnection does not allow receiving messages either, the messages gets > delivered if the broker was re started. > > Further drilling into the issue, it was noticed that the issue occurs > through all the acks sent by the subscribers being accumulated in the > distruptor ring. The distruptor ring was initialised with a buffer sized > 65536. > For MQTT QOS 0 case we mock the acks internally each time the message is > sent to the subscribers since for QOS 0 subscriber level acks do not > arrive, but acks are required for deletion of the message through the Andes > Kernal. As a result of acks being congested, this resulted in > the particular slot delivery worker thread to go into WAITING state. As a > result even if the subscriber disconnects and reconnects the messages will > not get delivered. > > Currently since the issue was found, we are in the process of debugging > and figuring our a solution. Will keep this thread updated on the findings. > > Thanks, > Pamod > > -- > *Pamod Sylvester * > *Senior Software Engineer * > Integration Technologies Team, WSO2 Inc.; http://wso2.com > email: [email protected] cell: +94 77 7779495 > -- *Pamod Sylvester * *Senior Software Engineer * Integration Technologies Team, WSO2 Inc.; http://wso2.com email: [email protected] cell: +94 77 7779495
_______________________________________________ Dev mailing list [email protected] http://wso2.org/cgi-bin/mailman/listinfo/dev
