DPL: drop special policy for Dispatcher#12788
Conversation
I suspect what is happening in the test is the consumers start too late (and the lossy policy drops messages on the sender side when that happens). This should avoid the problem by increasing the delay up to 1 second, before switching to lossy, giving enough time to the consumers to start.
|
REQUEST FOR PRODUCTION RELEASES: This will add The following labels are available |
|
@Barthelemy @knopers8 @davidrohr but then again, do we need at all a special policy for the dispatcher? Isn't it enough to make the dispatcher non-lossy if the task after it is not expendable (i.e. the default policy) and lossy if it is? |
seems plausible to me |
|
Yes, I think so. |
* DPL: attempt to have some dropping logic which does not break test I suspect what is happening in the test is the consumers start too late (and the lossy policy drops messages on the sender side when that happens). This should avoid the problem by increasing the delay up to 1 second, before switching to lossy, giving enough time to the consumers to start. * DPL: drop special policy for Dispatcher
* DPL: attempt to have some dropping logic which does not break test I suspect what is happening in the test is the consumers start too late (and the lossy policy drops messages on the sender side when that happens). This should avoid the problem by increasing the delay up to 1 second, before switching to lossy, giving enough time to the consumers to start. * DPL: drop special policy for Dispatcher
* DPL: attempt to have some dropping logic which does not break test I suspect what is happening in the test is the consumers start too late (and the lossy policy drops messages on the sender side when that happens). This should avoid the problem by increasing the delay up to 1 second, before switching to lossy, giving enough time to the consumers to start. * DPL: drop special policy for Dispatcher
3 participants
DPL: drop special policy for Dispatcher
Stack created with Sapling. Best reviewed with ReviewStack.