How frequently slow receivers occur
In practice, sending acknowledgements should not be slow because a dedicated thread sends acknowledgments. Network interruptions are the most common cause of delayed acknowledgments. Of course, network interruptions affect events being sent as well.
Most receivers, including the engine_receive tool, normally send acknowledgments 0.1 seconds after the message was sent. Consequently, there is very little chance of a receiver being mistakenly designated as slow. In production, slow receivers should be rare as long as you have done the appropriate load testing before deployment.
If an engine library client blocks in the middle of a sendEvents call, the receiver cannot acknowledge messages while the client is blocked. As you know, a receiver is made up of an engine library and a client. Clients receive events by registering a sendEvents callback with the engine library. When the engine library gets an event from the correlator, it calls sendEvents. Problems that can cause a client to block are typically related to I/O, networking, or synchronization. The sendEvents call cannot complete until the problem is resolved. The receiver cannot send the acknowledgement until the sendEvents call completes. For example, the engine_receive tool is a receiver that is made up of an engine library and a client whose sendEvents callback writes events received to a disk file. If the client has to wait for the disk, then it is blocked. The likelihood of a sendEvents callback being blocked depends on what the client is doing. If the client is writing to a local disk, the process might block sometimes, but never more than a fraction of a second. However, sending the events over a slow or unreliable network might block for a while if the network, or the remote system cannot keep up with the event rate.
During development of event consumers, however, slow receivers are more likely. This can happen when a newly developed consumer receives an event from the correlator but cannot send the acknowledgment because of a deadlock. Another development problem might be that the event consumer cannot keep up with the load. If you have problems with slow receivers during development, you probably need to evaluate the design of your application.