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.