Uploaded image for project: 'Qt'
  1. Qt
  2. QTBUG-106203

QMqttClient: Possible race condition on messageReceived signal

    XMLWordPrintable

Details

    • 5277f58a2a (qt/qtmqtt/dev) 5277f58a2a (qt/tqtc-qtmqtt/dev)

    Description

      User informed us that they  have a lambda that is called upon a messageReceived signal connected to subscription A. Within that lambda I subscribe to a set of other topics.

      Sometimes (not always) this triggers the same message to be delivered twice.

      They noticed that the delivery is done within a loop over all active subscriptions within the QMqttClient (finalize_publish method). They think that IF a subscription is added that inserts an entry in that activeSubcriptions table that is BEFORE the current sub, upon the next loop the sub is signaled again.

       

      They sent an example with a workaround:

      This is the code that works now we made the connection queued so that the subscribe within does not apply while the messageReceived is being executed:

       

       

      QMqttSubscription *sub = cl->subscribe("Identity");    
      connect(
              sub,
              &QMqttSubscription::messageReceived,
              this,        
              [this](QMqttMessage data) {
                  qDebug() << "Voertuiggroepeerder" << id << "received identity message." << this
                           << sender() << data.topic();
                      QString DetailTopic = QJsonDocument::fromJson(data.payload())["Unique_identifier"])
                        QMqttSubscription *sub2 = cl->subscribe(DetailTopic);
                       connect(
                             sub2,
                             &QMqttSubscription::messageReceived,
                             this,
                             [this](QMqttMessage data) {
                                    qDebug() << data.topic;
                             }
                       );
              },
              Qt::QueuedConnection); // to make it work
      
      
      
      
      

       

       

      Important for the demo is that there should already be messages waiting on the identity channel (message was published in retained mode by multiple
      publishers). this because we need messsages to arrivre while we are dispatching. The problem is a race condition: It does not always occur and the more
      publishers exist, the higher the chance of breakdown.

       

       

      Attachments

        Issue Links

          No reviews matched the request. Check your Options in the drop-down menu of this sections header.

          Activity

            People

              mkalinow Maurice Kalinowski
              tero.pelkonen Tero Pelkonen
              Votes:
              0 Vote for this issue
              Watchers:
              2 Start watching this issue

              Dates

                Created:
                Updated:
                Resolved:

                Gerrit Reviews

                  There are no open Gerrit changes