Uploaded image for project: 'AMQ Clients'
  1. AMQ Clients
  2. ENTMQCL-617

[cpp] Scheduling new work can starve out performing what has been scheduled before

    XMLWordPrintable

Details

    • July 2018

    Description

      This is my attempt at a workaround for ENTMQCL-600:

      while(true) {
          std::this_thread::sleep_for(std::chrono::microseconds(delay));
          amqS.container_->schedule(proton::duration::IMMEDIATE, [&]() {
              amqS.send(std::string(std::to_string(count)));
          });
      }
      

      The problem with the loop is that if the value of delay is small (under 20 microseconds), scheduling new send_fn's completely starves out the actual sending of the messages. The result is that the program schedules as many sends as it has credit for, and dies with the following output, not having sent a single message.

      queued 99996 credit 100000
      queued 99997 credit 100000
      queued 99998 credit 100000
      queued 99999 credit 100000
      queued 100000 credit 100000
      queued 100001 credit 100000
      Send Failed. Cant Recover Check Broker status / user/password
      
      Process finished with exit code 1
      

      Conceivably, in a different program this could lead to memory exhaustion.

      There could be limit on how many work items can be scheduled, and further calls to schedule could either block or fail. Alternatively, user of the API would need to be told to be careful not to call schedule() too often.

      Attachments

        Issue Links

          Activity

            People

              astitcher Andrew Stitcher
              jdanek@redhat.com Jiri Daněk
              Jiri Daněk Jiri Daněk
              Votes:
              0 Vote for this issue
              Watchers:
              3 Start watching this issue

              Dates

                Created:
                Updated:
                Resolved: