This message was deleted.
# general
s
This message was deleted.
a
Like, is this something I should be concerned about?
d
It depends on your data retention polices. If that falls within your policies then it is fine.
a
But it doesn’t, right?
My impression was that I set the namespace retention policy to one day only
And the topic has no policy set, so it should default to the namespace policy, yes?
d
If you don’t have an explicit topic policy, then yes, the namespace level policy applies. Also, has that message be acked on all subscriptions consuming from that topic? By default, Pulsar stores all unacknowledged messages forever.
a
As near as I can tell, yes. I tried to provide exhaustive logs of my calls to pulsar admin above, did you see them?
I can re link it here for convenience
d
You can get details on the status of topic subscriptions using the Pulsar admin cli. Topic stats and stats internal
I didn’t do stats internal though.
Would there be subscriptions hidden in there?
If you check out the paste in the link above, there are a few
pulsar-admin
calls in it, and what I was going for was to illustrate the namespace policy, lack of topic policy and topic stats showing only one subscription that seems to be caught up. Is there more I can add?
At least that’s what it looks like to me, what do you think?
d
The stats you shared indicate that all the messages have been consumed. So I am not sure why the earliest message command returns such an old message. 🤔
a
Okay so we have established that this is abnormal. Is there anything that could explain this other than a bug? Like a setting perhaps? Is there a command I can do to manually purge things?
Can I reset things by turning retention off? What happens in that case? Is there a way to know when it’s done so that I can turn it back on again?
d
It looks like a bug
If you change the retention policy, then you want to force an unload/closing of the current cursor to trigger any action on the segments in Pulsar, e.g., data deletion, tiered storage offload etc.
As old as this segment is, just an offload should suffice
a
Okay so something like 1. remove namespace policy 2.
pulsar-admin unload <namespace>
3. Wait 4. Add namespace policy
d
Yes but do another unload for step 5. Just to make sure the policy is loaded
Wait until yoy see that the namespace bundles are reassigned to a different broker
a
What’s the best way to verify that?
d
You should see messages in the broker log file
a
That's pretty manual. Any way to verify that with API calls?