This message was deleted.
# general
s
This message was deleted.
m
My general understanding is that you should be able to update these policies and have it "just work" such that decreasing retention leads to messages getting deleted while increasing retention leads to messages getting stored longer (with the obvious note that already deleted messages will be gone).
Did you see these docs yet?
If the docs don't answer your questions, I'm happy to grab some code references
a
For sure. I'm familiar with the broad concepts, how to set them and what they mean, but I was more curious about what happens when they're changed and how long that takes, whether there's a concern with accidentally changing them again while the change is ongoing, whether or not that matters or might lead to orphaned ledgers. Best practices stuff like that. The admin API makes it super easy to set these policies and get super granular
👍 1
but it's not clear what could go wrong and how to know what to do if it does
like, for example, if I have a retention set only on time and then I convert it to 50% of its former value, only to realize that 80% would be better, can I just issue the change to 80% immediately, or should I wait, and are there any risks and followup steps I need to take after such an action? Or, more broadly, are there checks I can be doing to ensure that retention and backlog are behaving within bounds and not just filling up disk with orphaned stuff?
m
When you update the retention policy, the update is applied to each affected topic (via its managed ledger) in an eventually consistent way. The first update is to the metadata store (zookeeper), and then all of the broker's will get notified of the updated state and will update the managed ledger configuration. The managed ledger then takes the retention policy into consideration by checking once every
retentionCheckIntervalInSeconds
(a broker setting that defaults to 120 seconds).
👏 1
a
That's great, thanks, that's a big part of what I was curious about!