Mikołaj Świątek

> 1. Batch processor uses a queue (implemented as a channel), which is not the same as the one used in the queue retry, that can lose data when the...

@bogdandrutu what do you think about making the batch processor conduct backpressure better in the meantime? Currently, batch processor simply ignores consumer errors. If a transient error happens later in...

@tigrannajaryan the reason I'd prefer to start with improving batch processor is that the change to it would be fairly straightforward and would improve user experience right now, as opposed...

I'm not sure this is good default behaviour. Persistent queue is often used to buffer data beyond memory capacity, so it might be larger and take longer to drain. It's...

> Yeah, I've been thinking about this. Can you expand your thoughts on this? Our current collector has an otlp receiver and then exports to the specific backends. Are you...

> > As I said earlier, I don't think the current API for storage clients is expressive enough to write a performant queue, even if the underlying store had all...

I don't think this is really bbolt's fault - we get a nice error because it doesn't allow concurrent access, but if it did, the collectors would clobber each others'...

> My concern with tying replicas to specific volumes (whether through paths or using StatefulSet) is making sure there is a way to ensure the persistent queue is completely drained...

> I am confused about this, I don't think the remounted happens for the existing pods. Imagine an app crash, then restart will pick the new version? Can you investigate...

> What does it mean? Is this what we have right now? What we have right now is automatic reload based on notifications from the config provider. I want to...