You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@pulsar.apache.org by zh...@apache.org on 2019/04/08 03:32:12 UTC

[pulsar.wiki] branch master updated: Updated PIP 34: Add new subscribe type Key_Failover (markdown)

This is an automated email from the ASF dual-hosted git repository.

zhaijia pushed a commit to branch master
in repository https://gitbox.apache.org/repos/asf/pulsar.wiki.git


The following commit(s) were added to refs/heads/master by this push:
     new 0cd56f3  Updated PIP 34: Add new subscribe type Key_Failover (markdown)
0cd56f3 is described below

commit 0cd56f3f5054192dd66d427af4d9b4b1426d6e72
Author: Jia Zhai <zh...@apache.org>
AuthorDate: Mon Apr 8 11:32:11 2019 +0800

    Updated PIP 34: Add new subscribe type Key_Failover (markdown)
---
 PIP-34:-Add-new-subscribe-type-Key_Failover.md | 9 +++++++++
 1 file changed, 9 insertions(+)

diff --git a/PIP-34:-Add-new-subscribe-type-Key_Failover.md b/PIP-34:-Add-new-subscribe-type-Key_Failover.md
index 6733cdc..1163c4c 100644
--- a/PIP-34:-Add-new-subscribe-type-Key_Failover.md
+++ b/PIP-34:-Add-new-subscribe-type-Key_Failover.md
@@ -16,6 +16,8 @@ The main idea is to bring a hash routing layer in new Key_Failover dispatcher. E
 The main work is on the hash layer and the new dispatcher.
 
 ### Hash layer
+As in the mail discussing, Any hash mechanism that can map a key to a
+consumer should work here.  We will make the hashing mechanism pluggable in this proposal.
 
 The hash value of message key determines the target consumer. The hash layer has the following requirements:
 1. Each consumer serves a fixed range of hash value.
@@ -37,6 +39,9 @@ There are 3 kinds of blocks, each block represents one consumer. vertical axis r
 1. at time T4, C2 is closed, and its hash range is assigned to C3. C3 will serve the whole range(0--1).
 
 ### change in PulsarApi.proto
+Add a new sub type in CommandSubscribe.SubType. 
+Add a new field in MessageMetadata, which served for this feature only. By using a new Key, it could avoid impacting other features. e.g. user want to use original key for compact/partition-routing, while want to use a new key for the key ordering.
+ 
 ```
 message CommandSubscribe {
 	enum SubType {
@@ -45,6 +50,10 @@ message CommandSubscribe {
 		Failover  = 2;
 		Key_Failover = 3; // add new type here < ==
 	}
+
+message MessageMetadata {
+	...
+	optional string ordering_key = 18;
 ```
 
 ### add a new dispatcher in broker side.