This is an automated email from the ASF dual-hosted git repository.
urfree pushed a commit to branch main
in repository https://gitbox.apache.org/repos/asf/pulsar-site.git
The following commit(s) were added to refs/heads/main by this push:
new 7ec609fc43e Docs sync done from apache/pulsar(#f23eb1f)
7ec609fc43e is described below
commit 7ec609fc43e8cd5f46fd0ef827196f3557def519
Author: Pulsar Site Updater <[email protected]>
AuthorDate: Fri May 27 06:55:28 2022 +0000
Docs sync done from apache/pulsar(#f23eb1f)
---
site2/website-next/docs/concepts-messaging.md | 7 ++++---
1 file changed, 4 insertions(+), 3 deletions(-)
diff --git a/site2/website-next/docs/concepts-messaging.md
b/site2/website-next/docs/concepts-messaging.md
index fc50500ef49..c5faba29d7d 100644
--- a/site2/website-next/docs/concepts-messaging.md
+++ b/site2/website-next/docs/concepts-messaging.md
@@ -800,7 +800,6 @@ Please pay attention that `JavaStringHash` is not useful
when producers can be f
## Non-persistent topics
-
By default, Pulsar persistently stores *all* unacknowledged messages on
multiple [BookKeeper](concepts-architecture-overview.md#persistent-storage)
bookies (storage nodes). Data for messages on persistent topics can thus
survive broker restarts and subscriber failover.
Pulsar also, however, supports **non-persistent topics**, which are topics on
which messages are *never* persisted to disk and live only in memory. When
using non-persistent delivery, killing a Pulsar broker or disconnecting a
subscriber to a topic means that all in-transit messages are lost on that
(non-persistent) topic, meaning that clients may see message loss.
@@ -815,12 +814,14 @@ non-persistent://tenant/namespace/topic
> For more info on using non-persistent topics, see the [Non-persistent
> messaging cookbook](cookbooks-non-persistent).
-In non-persistent topics, brokers immediately deliver messages to all
connected subscribers *without persisting them* in
[BookKeeper](concepts-architecture-overview.md#persistent-storage). If a
subscriber is disconnected, the broker will not be able to deliver those
in-transit messages, and subscribers will never be able to receive those
messages again. Eliminating the persistent storage step makes messaging on
non-persistent topics slightly faster than on persistent topics in some cases
[...]
+In non-persistent topics, brokers immediately deliver messages to all
connected subscribers *without persisting them* in
[BookKeeper](concepts-architecture-overview.md#persistent-storage). If a
subscriber is disconnected, the broker will not be able to deliver those
in-transit messages, and subscribers will never be able to receive those
messages again. Eliminating the persistent storage step makes messaging on
non-persistent topics slightly faster than on persistent topics in some cases
[...]
-> With non-persistent topics, message data lives only in memory. If a message
broker fails or message data can otherwise not be retrieved from memory, your
message data may be lost. Use non-persistent topics only if you're *certain*
that your use case requires it and can sustain it.
+> With non-persistent topics, message data lives only in memory, without a
specific buffer - which means data *is not* buffered in memory. The received
messages are immediately transmitted to all *connected consumers*. If a message
broker fails or message data can otherwise not be retrieved from memory, your
message data may be lost. Use non-persistent topics only if you're *certain*
that your use case requires it and can sustain it.
By default, non-persistent topics are enabled on Pulsar brokers. You can
disable them in the broker's
[configuration](reference-configuration.md#broker-enableNonPersistentTopics).
You can manage non-persistent topics using the `pulsar-admin topics` command.
For more information, see
[`pulsar-admin`](https://pulsar.apache.org/tools/pulsar-admin/).
+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.
+
### Performance
Non-persistent messaging is usually faster than persistent messaging because
brokers don't persist messages and immediately send acks back to the producer
as soon as that message is delivered to connected brokers. Producers thus see
comparatively low publish latency with non-persistent topic.
