Conversation
Rather than stopping ingestion on each interface after each wait, we can separate both concerns by waiting for all conditions, then stop all watchdog events at once.
There was a problem hiding this comment.
Hi,
I'm not sure to understand the motivation of this change.
All the purpose of chained wait/stop ingestion is a feature. There is a chain of component a -> b -> c; by chain, I mean the data flow is globally unidirectional, a sends to b, b sends to c.
The idea is that we wait for a, then actively stops a and then wait for b, etc
So every component will have its grace time to process all event received.
If we stops all watchdogs at once, we can have an event sent by a, that we won't see in b, if for any reason it kept it i a queue process.
|
I guess the change doesn't make sense standalone. I split this out while doing this POC: #1150 A grace period defined in time is prone to error: it's either too long most of the time and/or sometimes it's too short under some circumstances. So I'm experimenting with having an approach that is mostly time-independent and relies on precondition events happening, rather than hoping that implicit preconditions are met after a certain amount of time. |
|
Closing, since there's no value in this without further changes to the setup/wait model. |
|
You can adjust this time for any scenario. Now, about this :
It's not that easy. There are two different use cases :
The golden bullet for this is having a way to know that tracer/agent have processed everything they have to process. But as now, AFAIK, such a thing does not exists. |
2 participants
Description
Motivation
Rather than stopping ingestion on each interface after each wait, we can separate both concerns by waiting for all conditions, then stop all watchdog events at once.
Additional notes