-
This is another question about the informer, will the informer "resync" enqueue the older event? Let's say I have a Pod informer, and one POD produces events: CREATE, UPDATE, DELETE. For some reason, CREATE and DELETE events were consumed success, but the UPDATE event is not, after resync period, will the UPDATE event be re-enqueued and handled by the
Another question is, I know the resync is totally a client-side behavior, I find some blogs discussed the Go client implementation but not Java's, so, in which cases(exceeding event rate limit or queue quota?), the informer think the event should be re-enqueued during the resync? |
Beta Was this translation helpful? Give feedback.
Replies: 1 comment 6 replies
-
No, the informer will make only a single attempt at the event processing. It's entirely up to the handler if some retry or secondary queue is maintained. See a framework like the java operator sdk https://github.com/java-operator-sdk/java-operator-sdk that maintains a retriable event buffer above the informer level.
They will only be the same for a resync event.
The internals of the event queue and processing are completely different between the go and java implementations. As of now there is no circumstance under which the java implementation will reprocess a given event. At the next resync it will generate all applicable resync updates. Usage of the built-in resync is entirely optional. You can just as easily schedule a similar job only when you fail to process an event. |
Beta Was this translation helpful? Give feedback.
No, the informer will make only a single attempt at the event processing. It's entirely up to the handler if some retry or secondary queue is maintained.
See a framework like the java operator sdk https://github.com/java-operator-sdk/java-operator-sdk that maintains a retriable event buffer above the informer level.
They will only be the same for a resync event.
The internals of the event queue and processing are completely different between the go and java implementat…