Why are messages with qos 2 stuck on redis when we have that client connected and subscribled? about aedes HOT 15 CLOSED

Can you please upload a client & server to reproduce? Ideally in Node.js.

from aedes.

Broker file as below and logger file just generates logs to check if there are any errors. I have removed publish auth and sub scribe auth/connect auth from the file. Client you can pretty much use any (even any browser based or light weight client will do) Settings for client are

1. QOS 2
2. Clean : false
3. KeepAlive - 300

aedes version - 0.20.0
aedes-persistence-redis version - 2.3.0

(We have connect auth also but you can skip that)
Steps

1. Subscrible client 1 to a topic (Redis will show cached subscriptions and client)
2. Disconnect and connect client 2 (Redis will show cached subscriptions and client)
3. Publish to topic client 1 has above about 10 mesages with qos 2 / retained as false
4. Disconnect and connect back as client 1 and subscrible to topic

If you want exact files and tests let me know, I can write quick node project.

`
// MQTT Broker Setup
var logger = require('./config/logger');
var common = require('./config/common');
var config = common.config()

function aedesConnect() {
var redispersistence = require('aedes-persistence-redis')({
host: config.REDIS_CONNECTIONURL,
port: config.REDIS_PORT,
password: config.REDIS_PASSWORD
});

var aedes = require('aedes')({
    persistence: redispersistence,
    connectTimeout: config.MQTT_CONNECTTIMEOUT
});

var aedesServer = require('net').createServer(aedes.handle)

var settings = {
    port: config.MQTT_PORT,
};

// Authentication method
aedes.authenticate = function (client, username, password, callback) {
    var authorized = true
callback(null, authorized);
}

// Authorize Publish Method
aedes.authorizePublish = function (client, packet, callback) {
return callback(null)
}

////Authorize Subscribe Method
aedes.authorizeSubscribe = function (client, sub, callback) {
    callback(null, sub)
}


var port = 1883

aedesServer.listen(port, function () {
    logger.info('mqtt broker listening on port ' + port)
})


aedes.on('clientError', function (client, err) {
    logger.error(err)
    logger.error('client error', client.id, err.message)
})

aedes.on('clientDisconnect', function (client) {
    logger.info('Client disconnected - ', client.id)
})

aedes.on('unsubscribe', function (unsubscriptions, client) {
    logger.info('Client unsubscribed - ', client.id, unsubscriptions.toString())
})

aedes.on('publish', function (packet, client) {
    if (client) {
        logger.info('message published from client', client.id, " to ", packet.topic, packet.messageId)
    }
    else {
        logger.info('message published from broker to ', packet.topic, packet.messageId)
    }
})

aedes.on('client', function (client) {
    logger.info('new client', client.id)
})

return aedes;

}

module.exports = aedesConnect
`

from aedes.

I cannot reproduce, things works smoothly here. Please upload a test client that makes the server exhibit the bug.

I am publishing a QoS 2 message with retain:false using MQTT.js.

Which version of Redis are you using? I'm testing on 3.2.0.

from aedes.

I am using redis version 3.0.3
I will replicate it with MQTT.js and paste details here

from aedes.

@mcollina We were facing a lot of issues and have switched to mosquitto and we have had no problems since then. I definitely want to contribute to this amazing project and will add sample client files to replicate the issues but to summarize issue is -

QOS2 offline messages are not delivered in order and all of them are not delivered but in chunks of 4 or less. So if I sent 10 messages when client 2 is disconnected, whenever it conencts back it wont get all 10 and also in random order.

Will add sample client files and broker files in couple of days as we are having a release tomorrow.
Thank you for all the help.

from aedes.

I've done another round of testing, confirmed odd behavior both with redis and without.

Thanks for reporting, I'll look into it as soon as possible (it might take a while).

from aedes.

Hello @mcollina, could you describe the error, I'm facing the same problem, the clients are receiving the same message multiple times.
If could you describe it a bit, I could help and make a PR.

Thanks!

from aedes.

@igormontella thanks! Really, I have just tested the above code. This needs to be triaged and debugged, feel free to dig into it and report with any questions, it will make solving this much quicker.

from aedes.

@guptaashishiitr @igormontella We made some change in aedes-persistence redis. Could you guys check if you're still facing this issue ?

from aedes.

@GavinDmello , Offline messages are not delivered in order ,tested with both QoS1 and Qos2 .

from aedes.

@rasalasantosh Are you getting all of them though ?

from aedes.

@GavinDmello ,yes all are delivered.

from aedes.

@rasalasantosh Got it @mcollina I think scan returns data in random order

from aedes.

I'm starting to think that using SCAN was not a good idea in the first place. Maybe we should go for the same approach of Mosca.

from aedes.

I think this should be solved in the latest version of redis persistence redis

from aedes.