Hello, I have multiple questions regarding non-per...
# general
t
Hello, I have multiple questions regarding non-persistent topics (Pulsar 3.2.0). I have 3 node cluster (each node has broker, bookie, zookeeper installed). Created non-persistent non-partitioned topic in one node and playing with admin api calls on this topic.
GET <https://localhost:8443/admin/v2/non-persistent/tenant/ns/topic/internal-info>
- fails with http status code 500 "Error 500 Request failed". I'll check if I can find the log.
GET <https://localhost:8443/admin/v2/non-persistent/tenant/ns/topic/unload>
- removes the topic from broker but does not recreate it? Is it normal?
GET <https://localhost:8443/admin/v2/non-persistent/tenant/ns/topic/compaction>
- correct redirect (307) if broker does not serve the topic, but exception from the serving broker (see thread)
GET <https://localhost:8443/admin/v2/non-persistent/tenant/ns/topic/partitions>
- no redirect (307) if broker does not own the topic, but 404
"reason": "Topic <non-persistent://tenant/ns/topic> not found"
Most uncomfortable is the
/partitions
error because terraform provider uses this command and fails if it gets 404. Should I used partitioned topic (3 partitions) to avoid this error?
Exception while sending admin api /compaction request for non-persistent topic
l
There's a large amount of fixes since version 3.2.0 . Please test with most recent version 3.2.3 and if problems still exist, please report to https://github.com/apache/pulsar/issues .
t
I'll try it out. And create the issues if necessary
l
non-persistent topics don't have message delivery guarantees. that's perhaps one of the reasons why not much attention is paid to support them for all APIs.
t
Can you suggest where I can read in more detail about non-persistent topics and partitioning? I can find one article about partitioning here
And I am not a developer, reading code doesn't help me 😐
Got the probable answer for the
/unload
admin api request (non-persistent topic is not recreated): > Currently, non-persistent topics which are not partitioned are not persisted to ZooKeeper, which means if the broker owning them crashes, they do not get re-assigned to another broker because they only exist in the owner broker memory. The current workaround is to set the value of
allowAutoTopicCreation
to
true
and
allowAutoTopicCreationType
to
non-partitioned
(they are default values) in broker configuration.