sijie closed pull request #2230: Make doc image links work when there is a base
path.
URL: https://github.com/apache/incubator-pulsar/pull/2230
This is a PR merged from a forked repository.
As GitHub hides the original diff on merge, it is displayed below for
the sake of provenance:
As this is a foreign pull request (from a fork), the diff is supplied
below (as it won't show otherwise due to GitHub magic):
diff --git a/site2/docs/administration-geo.md b/site2/docs/administration-geo.md
index 08c7b3ee29..c50563968f 100644
--- a/site2/docs/administration-geo.md
+++ b/site2/docs/administration-geo.md
@@ -10,7 +10,7 @@ sidebar_label: Geo-replication
The diagram below illustrates the process of geo-replication across Pulsar
clusters:
-
+
In this diagram, whenever producers **P1**, **P2**, and **P3** publish
messages to the topic **T1** on clusters **Cluster-A**, **Cluster-B**, and
**Cluster-C**, respectively, those messages are instantly replicated across
clusters. Once replicated, consumers **C1** and **C2** can consume those
messages from their respective clusters.
diff --git a/site2/docs/administration-zk-bk.md
b/site2/docs/administration-zk-bk.md
index cf0eb3a079..79ee037a0f 100644
--- a/site2/docs/administration-zk-bk.md
+++ b/site2/docs/administration-zk-bk.md
@@ -329,6 +329,6 @@ PersistencePolicies policies =
admin.namespaces().getPersistence(namespace);
This diagram illustrates the role of ZooKeeper and BookKeeper in a Pulsar
cluster:
-
+
Each Pulsar cluster consists of one or more message brokers. Each broker
relies on an ensemble of bookies.
diff --git a/site2/docs/cookbooks-encryption.md
b/site2/docs/cookbooks-encryption.md
index 1bf22c9999..e11b1310bb 100644
--- a/site2/docs/cookbooks-encryption.md
+++ b/site2/docs/cookbooks-encryption.md
@@ -19,10 +19,10 @@ A message can be encrypted with more than one key. Any one
of the keys used for
Pulsar does not store the encryption key anywhere in the pulsar service. If
you lose/delete the private key, your message is irretrievably lost, and is
unrecoverable
## Producer
-
+
## Consumer
-
+
## Here are the steps to get started:
diff --git a/site2/docs/cookbooks-tiered-storage.md
b/site2/docs/cookbooks-tiered-storage.md
index 792592e4a2..003cd14a7e 100644
--- a/site2/docs/cookbooks-tiered-storage.md
+++ b/site2/docs/cookbooks-tiered-storage.md
@@ -14,7 +14,7 @@ Tiered storage should be used when you have a topic for which
you want to keep a
A topic in Pulsar is backed by a log, known as a managed ledger. This log is
composed of an ordered list of segments. Pulsar only every writes to the final
segment of the log. All previous segments are sealed. The data within the
segment is immutable. This is known as a segment oriented architecture.
-
+
{% include figure.html src="/img/pulsar-tiered-storage.png" alt="Tiered
Storage" width="80" %}
diff --git a/site2/docs/deploy-bare-metal.md b/site2/docs/deploy-bare-metal.md
index 6fb1f1d412..8b3497fc7b 100644
--- a/site2/docs/deploy-bare-metal.md
+++ b/site2/docs/deploy-bare-metal.md
@@ -26,7 +26,7 @@ Each machine in your cluster will need to have [Java
8](http://www.oracle.com/te
Here's a diagram showing the basic setup:
-
+
In this diagram, connecting clients need to be able to communicate with the
Pulsar cluster using a single URL, in this case `pulsar-cluster.acme.com`, that
abstracts over all of the message-handling brokers. Pulsar message brokers run
on machines alongside BookKeeper bookies; brokers and bookies, in turn, rely on
ZooKeeper.
diff --git a/site2/docs/deploy-dcos.md b/site2/docs/deploy-dcos.md
index 62dfd8150d..64b3d962b5 100644
--- a/site2/docs/deploy-dcos.md
+++ b/site2/docs/deploy-dcos.md
@@ -48,69 +48,69 @@ This command will deploy Docker container instances in
three groups, which toget
After executing the `dcos` command above, click on the **Services** tab in the
DC/OS [GUI interface](https://docs.mesosphere.com/latest/gui/), which you can
access at [http://m1.dcos](http://m1.dcos) in this example. You should see
several applications in the process of deploying.
-
+
-
+
## The BookKeeper group
To monitor the status of the BookKeeper cluster deployment, click on the
**bookkeeper** group in the parent **pulsar** group.
-
+
At this point, 3 {% popover bookies %} should be shown as green, which means
that they have been deployed successfully and are now running.
-
+
You can also click into each bookie instance to get more detailed info, such
as the bookie running log.
-
+
To display information about the BookKeeper in ZooKeeper, you can visit
[http://m1.dcos/exhibitor](http://m1.dcos/exhibitor). In this example, there
are 3 bookies under the `available` directory.
-
+
## The Pulsar broker Group
Similar to the BookKeeper group above, click into the **brokers** to check the
status of the Pulsar brokers.
-
+
-
+
You can also click into each broker instance to get more detailed info, such
as the broker running log.
-
+
Broker cluster information in Zookeeper is also available through the web UI.
In this example, you can see that that the `loadbalance` and `managed-ledgers`
directories have been created.
-
+
## Monitor Group
The **monitory** group consists of Prometheus and Grafana.
-
+
### Prometheus
Click into the instance of `prom` to get the endpoint of Prometheus, which is
`192.168.65.121:9090` in this example.
-
+
If you click that endpoint, you'll see the Prometheus dashboard. The
[http://192.168.65.121:9090/targets](http://192.168.65.121:9090/targets) URL
will display all the bookies and brokers.
-
+
### Grafana
Click into `grafana` to get the endpoint for Grafana, which is
`192.168.65.121:3000` in this example.
-
+
If you click that endpoint, you can access the Grafana dashbaord.
-
+
## Run a simple Pulsar consumer and producer on DC/OS
@@ -151,15 +151,15 @@ $ mvn exec:java
-Dexec.mainClass="tutorial.ProducerTutorial"
You can see the producer producing messages and the consumer consuming
messages through the DC/OS GUI.
-
+
-
+
### View Grafana metric output
While the producer and consumer are running, you can access running metrics
information from Grafana.
-
+
## Uninstall Pulsar
@@ -168,7 +168,7 @@ You can shut down and uninstall the `pulsar` application
from DC/OS at any time
1. Using the DC/OS GUI, you can choose **Delete** at the right end of Pulsar
group.
- 
+ 
2. You can use the following command:
diff --git a/site2/docs/developing-binary-protocol.md
b/site2/docs/developing-binary-protocol.md
index dfe3365c7d..1dd6c48534 100644
--- a/site2/docs/developing-binary-protocol.md
+++ b/site2/docs/developing-binary-protocol.md
@@ -99,7 +99,7 @@ When compression is enabled, the whole batch will be
compressed at once.
After opening a TCP connection to a broker, typically on port 6650, the client
is responsible to initiate the session.
-
+
After receiving a `Connected` response from the broker, the client can
consider the connection ready to use. Alternatively, if the broker doesn't
@@ -164,7 +164,7 @@ authorized to publish on the topic.
Once the client gets confirmation of the producer creation, it can publish
messages to the broker, referring to the producer id negotiated before.
-
+
##### Command Producer
@@ -277,7 +277,7 @@ A consumer is used to attach to a subscription and consume
messages from it.
After every reconnection, a client needs to subscribe to the topic. If a
subscription is not already there, a new one will be created.
-
+
#### Flow control
@@ -458,7 +458,7 @@ connect to, or a broker hostname to which retry the lookup.
The `LookupTopic` command has to be used in a connection that has already
gone through the `Connect` / `Connected` initial handshake.
-
+
```protobuf
message CommandLookupTopic {
diff --git a/site2/docs/functions-overview.md b/site2/docs/functions-overview.md
index e0ea6d61a7..d7c2b505ad 100644
--- a/site2/docs/functions-overview.md
+++ b/site2/docs/functions-overview.md
@@ -61,13 +61,13 @@ The core programming model behind Pulsar Functions is very
simple:
* Write logs to a **log topic** (potentially for debugging purposes)
* Increment a [counter](#counters)
-
+
### Word count example
If you were to implement the classic word count example using Pulsar
Functions, it might look something like this:
-
+
If you were writing the function in [Java](functions-api.md#java) using the
[Pulsar Functions SDK for Java](functions-api.md#java-sdk), you could write the
function like this...
@@ -111,7 +111,7 @@ The use cases for Pulsar Functions are essentially endless,
but let's dig into a
Imagine a function that takes items (strings) as input and publishes them to
either a fruits or vegetables topic, depending on the item. Or, if an item is
neither a fruit nor a vegetable, a warning is logged to a [log
topic](#logging). Here's a visual representation:
-
+
If you were implementing this routing functionality in Python, it might look
something like this:
diff --git a/site2/docs/getting-started-concepts-and-architecture.md
b/site2/docs/getting-started-concepts-and-architecture.md
index 3ee3c18db5..e290753038 100644
--- a/site2/docs/getting-started-concepts-and-architecture.md
+++ b/site2/docs/getting-started-concepts-and-architecture.md
@@ -116,7 +116,7 @@ A namespace is a logical nomenclature within a tenant. A
tenant can create multi
A subscription is a named configuration rule that determines how messages are
delivered to consumers. There are three available subscription modes in Pulsar:
[exclusive](#exclusive), [shared](#shared), and [failover](#failover). These
modes are illustrated in the figure below.
-
+
#### Exclusive
@@ -126,7 +126,7 @@ In the diagram above, only **Consumer-A** is allowed to
consume messages.
> Exclusive mode is the default subscription mode.
-
+
#### Shared
@@ -139,7 +139,7 @@ In the diagram above, **Consumer-B-1** and **Consumer-B-2**
are able to subscrib
> * Message ordering is not guaranteed.
> * You cannot use cumulative acknowledgment with shared mode.
-
+
#### Failover
@@ -149,7 +149,7 @@ When the master consumer disconnects, all (non-acked and
subsequent) messages wi
In the diagram above, Consumer-C-1 is the master consumer while Consumer-C-2
would be the next in line to receive messages if Consumer-C-2 disconnected.
-
+
### Multi-topic subscriptions
@@ -196,7 +196,7 @@ Behind the scenes, a partitioned topic is actually
implemented as N internal top
The diagram below illustrates this:
-
+
Here, the topic **Topic1** has five partitions (**P0** through **P4**) split
across three brokers. Because there are more partitions than brokers, two
brokers handle two partitions a piece, while the third handles only one (again,
Pulsar handles this distribution of partitions automatically).
@@ -281,7 +281,7 @@ In a Pulsar cluster:
The diagram below provides an illustration of a Pulsar cluster:
-
+
At the broader instance level, an instance-wide ZooKeeper cluster called the
configuration store handles coordination tasks involving multiple clusters, for
example [geo-replication](#replication).
@@ -347,7 +347,7 @@ persistent://my-property/my-namespace/my-topic
You can see an illustration of how brokers and bookies interact in the diagram
below:
-
+
### Ledgers
@@ -395,7 +395,7 @@ Pulsar has two features, however, that enable you to
override this default behav
The diagram below illustrates both concepts:
-
+
With message retention, shown at the top, a <span style="color:
#89b557;">retention policy</span> applied to all topics in a namespace dicates
that some messages are durably stored in Pulsar even though they've already
been acknowledged. Acknowledged messages that are not covered by the retention
policy are <span style="color: #bb3b3e;">deleted</span>. Without a retention
policy, *all* of the <span style="color: #19967d;">acknowledged messages</span>
would be deleted.
@@ -415,7 +415,7 @@ Message **duplication** occurs when a message is
[persisted](#persistent-storage
The following diagram illustrates what happens when message deduplication is
disabled vs. enabled:
-
+
Message deduplication is disabled in the scenario shown at the top. Here, a
producer publishes message 1 on a topic; the message reaches a Pulsar broker
and is [persisted](#persistent-storage) to BookKeeper. The producer then sends
message 1 again (in this case due to some retry logic), and the message is
received by the broker and stored in BookKeeper again, which means that
duplication has occurred.
@@ -535,7 +535,7 @@ You can use your own service discovery system if you'd
like. If you use your own
The diagram below illustrates Pulsar service discovery:
-
+
In this diagram, the Pulsar cluster is addressable via a single DNS name:
`pulsar-cluster.acme.com`. A [Python client](client-libraries-python.md), for
example, could access this Pulsar cluster like this:
@@ -557,7 +557,7 @@ The **reader interface** for Pulsar enables applications to
manually manage curs
The reader interface is helpful for use cases like using Pulsar to provide
[effectively-once](https://streaml.io/blog/exactly-once/) processing semantics
for a stream processing system. For this use case, it's essential that the
stream processing system be able to "rewind" topics to a specific message and
begin reading there. The reader interface provides Pulsar clients with the
low-level abstraction necessary to "manually position" themselves within a
topic.
-
+
> ### Non-partitioned topics only
> The reader interface for Pulsar cannot currently be used with [partitioned
> topics](#partitioned-topics).
@@ -639,7 +639,7 @@ Pulsar's segment oriented architecture allows for topic
backlogs to grow very la
One way to alleviate this cost is to use Tiered Storage. With tiered storage,
older messages in the backlog can be moved from bookkeeper to a cheaper storage
mechanism, while still allowing clients to access the backlog as if nothing had
changed.
-
+
> Data written to bookkeeper is replicated to 3 physical machines by default.
> However, once a segment is sealed in bookkeeper is becomes immutable and can
> be copied to long term storage. Long term storage can achieve cost savings
> by using mechanisms such as [Reed-Solomon error
> correction](https://en.wikipedia.org/wiki/Reed%E2%80%93Solomon_error_correction)
> to require fewer physical copies of data.
@@ -664,7 +664,7 @@ Pulsar IO connectors come in two types:
This diagram illustrates the relationship between sources, sinks, and Pulsar:
-
+
### Working with connectors
diff --git a/site2/docs/io-overview.md b/site2/docs/io-overview.md
index 781fb0e0ca..56a36f25ac 100644
--- a/site2/docs/io-overview.md
+++ b/site2/docs/io-overview.md
@@ -18,7 +18,7 @@ Pulsar IO connectors come in two types:
This diagram illustrates the relationship between sources, sinks, and Pulsar:
-
+
## Working with connectors
diff --git a/site2/docs/security-encryption.md
b/site2/docs/security-encryption.md
index b2b3b14346..133d85b34c 100644
--- a/site2/docs/security-encryption.md
+++ b/site2/docs/security-encryption.md
@@ -19,10 +19,10 @@ A message can be encrypted with more than one key. Any one
of the keys used for
Pulsar does not store the encryption key anywhere in the pulsar service. If
you lose/delete the private key, your message is irretrievably lost, and is
unrecoverable
## Producer
-
+
## Consumer
-
+
## Here are the steps to get started:
----------------------------------------------------------------
This is an automated message from the Apache Git Service.
To respond to the message, please log on GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
[email protected]
With regards,
Apache Git Services
