.suppress(Suppressed.untilWindowCloses(Suppressed.BufferConfig.unbounded())
I currently use the above construct to configure a suppress operator in my kstreams topology.
The documentation for the unbounded strict-buffer config mentions the possibility of an OOM if there are too many events in a given window for the suppress operator to buffer.
However, I also see that the suppress operator has an underlying implicit state store created. This state store is disk based rocksdb file. If there are too many events in a given window shouldn't it be managed by a spill-over to the underlying state-store?
Or am I missing something fundamental here?
I ideally want to use the unbounded strict buffer as it ensures that only the last aggregated value in the window is emitted(I aggregate in my windows in my topology). Intermediate results being emitted are not ideal to the semantics of the message that my topology generates to downstream consumers.
