在 Apache Pulsar 2.6.0 版本發布後的 2 個月，2020 年 8 月 21 日，Apache Pulsar 2.6.1 版本正式發布！
Apache Pulsar 2.6.1 修復了 2.6.0 版本中的諸多問題，改進了一些功能，新增了對 OAuth2 的支持，覆蓋 Broker、Pulsar SQL、Pulsar Functions、Go Function、Java Client 和 C++ Client，進一步豐富了 Pulsar 作為雲原生流數據平臺的功能。
在 Pulsar 2.6.1 版本中，來自社區的 commit 有 102 個，越來越多的小夥伴開始參與到 Pulsar 社區建設中，成為 Contributor 的一員。下面一起來看看 2.6.1 版本有哪些更新吧。
Broker 相關改進📣 將批處理大小限制為 「maxNumberOfMessages」 和 「 maxSizeOfMessages」 的最小值在 2.6.0 版本之前，BatchReceive 策略中 maxNumberOfMessages 和maxSizeOfMessages 的最小值不會影響批處理大小。當批量大小大於 consumer 中設置的 receiveQueue 大小時（假設使用的批量大小為 3000，receiveQ 為 500），會出現以下問題：
在 consumer 中使用多主題模式，client 被阻塞，導致不接收任何消息；即使用戶在批處理中設置超時策略，client 也不會恢復。
在 2.6.1 版本中，我們把批處理大小設置為 「maxNumberOfMessages」 和 「maxSizeOfMessages」 中的最小值，修復了該問題。
更多詳情查看 PR-6865：https://github.com/apache/pul...。
📣 解決 Key_Shared 中使用粘性 hash range 導致的哈希範圍衝突問題在以前的版本中，當用戶在 Key_Shared 訂閱模型中使用 「stickyHashRange」 時，consumer 指定的 hash 範圍不允許重疊。例如，consumer-1 的哈希範圍為：[[0,99]，[400,65535]]，consumer-2 的哈希範圍為：[[100,399]]。
這是因為在 broker 端，沒有對 stick hash range 中的 start 和 end 位置進行檢查。正常情況下不允許 start 大於 end 的位置。在 2.6.1 版本中，我們加入了相應的 check 機制，來避免出現 hash range 衝突的問題。
更多詳情查看 PR-7231：https://github.com/apache/pul...。
📣 修復獲取 lookup 權限的錯誤當前，當 Pulsar AuthorizationService 檢查 lookup 權限時，擁有 canProducer 或 canConsumer 角色應該具備可以 canLookup 的能力，但實際上並沒有該能力。代碼如下：
javatry { return canLookupAsync(topicName, role, authenticationData) .get(conf.getZooKeeperOperationTimeoutSeconds(), SECONDS);}
如果 canProduce 或 canConsume 方法拋出異常，canLookup 只會拋出該異常，不檢查其他權限。
在 2.6.1 版本中，使用 canLookupAsync 代替原來的行為，更多詳情查看 PR-7234：https://github.com/apache/pul... 。
📣 修復創建 non-durable cursor 時無法刪除 topic 的錯誤當非持久遊標創建失敗時，會返回 NPE。因為程序發生 NPE 後，仍在繼續創建訂閱實例：
javatry { cursor = ledger.newNonDurableCursor(startPosition, subscriptionName);} catch (ManagedLedgerException e) { subscriptionFuture.completeExceptionally(e);}return new PersistentSubscription(this, subscriptionName, cursor, false);
將導致該 topic 的引用計數加一。當用戶想要刪除這個 topic 時，由於引用計數沒有清零，所以即使使用 --force 強制刪除，也無法刪除 topic。在 2.6.1 版本中，我們解決了無法刪除 topic 的問題。
更多詳情查看 PR-7355：https://github.com/apache/pul...。
📣 避免在 ManagedLedgerImpl.isOffloadedNeedsDelete 方法中發生 NPE在 2.6.1 版本之前，offload-deletion-lag 的默認值為 null，導致了 NPE 問題。在 2.6.1 版本中，我們在 ManagedLedgerImpl.isOffloadedNeedsDelete 方法中添加對 null 值的檢查，避免出現該問題。
更多詳情查看 PR-7389：https://github.com/apache/pul... 。
📣 修復創建新 ledger 時引發 NPE 導致生產者卡死的問題由於無法解析網絡地址，在創建 ledger 時會引發 NPE。如果在添加超時任務之前引發了 NPE，則超時機制不起作用。無法解析的網絡地址在 Kubernetes 環境中很常見。當 bookie pod 或工作程序節點重新啟動時，可能會發生這種情況。
在 2.6.1 版本中，可通過以下操作來修復該問題:
在創建一個新的 ledger 時，捕獲這個 NPE； 觸發超時任務時，始終執行回調。因為回調只能觸發一次； 添加機制檢測 「CreatingLedger」 狀態是否發生變化。更多詳情查看 PR-7401：https://github.com/apache/pul...。
📣 修復使用 advertisedListeners 產生的 NPE 問題當使用帶有外部 listener 名稱的 advertisedListeners = internal：pulsar：// node1：6650，external：pulsar：//node1.external：6650 時，broker 無法獲取名稱空間包的所有權。如果未啟用 TLS，我們需要更改 BrokerServiceUrlTls。
更多詳情查看 PR-7620：https://github.com/apache/pul... 。
📣 獲取最後一條 entry 時，client 錯誤地讀取 -1 這條 entry在 2.6.1 版本之前，getLargestBatchIndexWhenPossible() 函數沒有 return 語句，當 entry 為 -1時，client 會對把相應的 MessageData 設置為當前位置的值，並將該值發送到 client，當 client 嘗試讀取該 entry，會出現如下問題：
16:34:25.779 [pulsar-io-54-7:org.apache.bookkeeper.client.LedgerHandle@748] ERROR org.apache.bookkeeper.client.LedgerHandle - IncorrectParameterException on ledgerId:0 firstEntry:-1 lastEntry:-116:34:25.779 [pulsar-client-io-82-1:org.apache.pulsar.client.impl.ConsumerImpl@1986] INFO org.apache.pulsar.client.impl.ConsumerImpl - [persistent://external-repl-prop/pulsar-function-admin/assignment][c-use-fw-localhost-0-function-assignment-initialize-reader-b21f7607c9] Successfully getLastMessageId 0:-116:34:25.779 [pulsar-client-io-82-1:org.apache.pulsar.client.impl.ClientCnx@602] WARN org.apache.pulsar.client.impl.ClientCnx - [id: 0xc78f4a0e, L:/127.0.0.1:55657 - R:localhost/127.0.0.1:55615] Received error from server: Failed to get batch size for entry org.apache.bookkeeper.mledger.ManagedLedgerException: Incorrect parameter input16:34:25.779 [pulsar-client-io-82-1:org.apache.pulsar.client.impl.ClientCnx@612] WARN org.apache.pulsar.client.impl.ClientCnx - [id: 0xc78f4a0e, L:/127.0.0.1:55657 - R:localhost/127.0.0.1:55615] Received unknown request id from server: 10
PR-7495 在代碼中增加了 return 語句，GetLastEntry() 會讀取最後一條 entry，而不是 -1。
更多詳情查看 PR-7495：https://github.com/apache/pul...。
ZooKeeper 相關改進📣 使用主機名進行 Bookie 機架感知映射PR-5607 中添加了 useHostName() 和 return false。這意味著機架式策略會嘗試將 Bookie 主機名解析為 IP 地址，然後使用該 IP 地址來確定 Bookie 屬於哪個機架。
這會導致如下兩個問題：
IP 地址與在/ bookies z-節點中記錄的主機名不匹配； 如果在解析 bookie 主機名時發生錯誤（例如：瞬態 DNS 錯誤），會觸發 NPE 異常；對 BookKeeper 客戶端來說，該 bookie 在集群中一直不可用。例如，在下面代碼中的第 77 行會拋出 NPE，因為 getAddress() 給出了一個 null，而該地址沒有解析：
java74 if (dnsResolver.useHostName()) {75 names.add(addr.getHostName());76 } else {77 names.add(addr.getAddress().getHostAddress());78 }
默認情況下，DnsResolver.useHostName() 返回 true。
更多詳情參考 PR-7361：https://github.com/apache/pul...。
Java Client 相關改進📣 修復了無法重命名 Athenz 身份驗證中使用的 HTTP header 的問題Athenz 的身份驗證插件允許用戶更改 HTTP header 的名稱，並通過 roleHeader 參數將身份驗證令牌發送到代理伺服器。更改 HTTP header 名稱會保留 「AuthenticationAthenz」 側的 「roleHeader」 參數的值，並將其直接用作標頭名稱。
更多詳情參考 PR-7311：https://github.com/apache/pul...。
📣 修復多次回收 batch ack 的集合多次回收 batch ack 的根本原因是批量 Ack 刷新和累積確認中存在競爭條件。因此，為該 ackset 添加回收狀態檢查，避免多次回收 batch ack。
更多詳情參考 PR-7409：https://github.com/apache/pul...。
📣 添加支持 OAuth2 身份驗證的客戶端Pulsar 支持使用 OAuth 2.0 訪問令牌驗證客戶端身份。可以使用令牌來標識 Pulsar 客戶端，並將令牌關聯到允許執行某些操作（例如：發布到主題或從主題消費）的某些 「principal」（或「role」）。
該模塊直接支持 OAuth 2.0 的 Pulsar 客戶端身份驗證插件。客戶端與 OAuth 2.0 伺服器進行通信後，將從 OAuth 2.0 伺服器獲取「訪問令牌」，並將該「訪問令牌」傳遞給 Pulsar broker 進行身份驗證。
因此，代理方仍然可以使用 「org.apache.pulsar.broker.authentication.AuthenticationProviderToken」，
用戶也可以添加自己的 AuthenticationProvider 來使用此模塊。
更多詳情參考 PR-7420：https://github.com/apache/pul...。
📣 在 consumer 關閉之後，不再訂閱這個 topic當 consumer 重新連接到 broker 時，將競爭條件固定在 consumer 中。
在 consumer 重新連接到代理時會發生競爭條件，消費者重新連接到代理時連接設置為 null。如果此時關閉 cosnumer，客戶端不再向代理髮送關閉 consumer 的命令。因此，如果 consumer 重新連接到 broker，consuemr 將再次發送訂閱命令。
在 2.6.1 版本中，當 consumer 的連接打開時，consumer 會添加狀態檢查。如果使用者狀態為關閉或正在關閉，則無需發送訂閱命令。
更多詳情參考 PR-7589：https://github.com/apache/pul...。
📣 OAuth2 身份驗證插件使用 AsyncHttpClient在之前的版本中，OAuth2 客戶端 auth 插件使用 Apache HTTP 客戶端庫發出請求，Apache HTTP 客戶端僅用於主機名驗證。如 PR-7612 所述，為了擺脫對 Apache HTTP 客戶端庫的依賴，在 2.6.1 版本中使用 AsyncHttpClient。AsyncHttpClient 在客戶端和 broker 中的其他地方都有使用。
更多詳情參考 PR-7615：https://github.com/apache/pul...。
CPP Client 相關改進📣 在 CPP 客戶端中支持 OAuth2 的認證方式Pulsar 支持使用 OAuth 2.0 訪問令牌對客戶端進行身份驗證。可以使用令牌來標識 Pulsar 客戶端，並將其與允許執行某些操作（例如：發布到主題或從主題消費）的某些「principal」（或「role」）關聯。
在 2.6.1 版本中，允許用戶在 CPP 客戶端中使用 OAuth2 的認證方式。
更多詳情參考 PR-7467：https://github.com/apache/pul...。
📣 修復在關閉 callback 中 partition 索引的錯誤在分區生產者/消費者中關閉 callback 時，分區索引始終為 0。我們需要將 ProducerImpl / ConsumerImpl 的內部 partition 索引欄位傳遞給 PartitionedProducerImpl / PartitionedConsumerImpl 的 close 回調。
更多詳情參考 PR-7282：https://github.com/apache/pul...。
📣 修復了 C++ 客戶端中計時器的競爭狀況導致的段崩潰在 2.6.1 版本之前，競爭條件下會發生段崩潰：
關閉操作，稱為 「keepAliveTimer_.reset()」； 同時，在 startConsumerStatsTimer 和 handleKeepAliveTimeout 方法中訪問計時器。在 2.6.1 版本中，我們修復了此問題，競爭條件下不再發生段崩潰。
更多詳情參考 PR-7572：https://github.com/apache/pul...。
📣 支持從文件讀取憑據支持從文件讀取憑據，使其與 Java 客戶端保持一致。
更多詳情參考 PR-7606：https://github.com/apache/pul...。
📣 修復在連接出錯時多 topic consumer 的段錯誤當創建 consumer 出現錯誤時，多主題 consumer 將觸發段錯誤。這是使用 null 回調關閉部分使用者的調用所致。
在 2.6.1 版本中，我們修復了此問題。
更多詳情參考 PR-7588：https://github.com/apache/pul...。
Functions 相關改進📣 使用標準主機名作為 worker 的默認值Java 8 和 Java 11 獲取主機名的方法不同。在 Java 8 中，使用 InetAddress.getLocalHost（）參數，getHostName()返回完全限定的主機名。在 Java 11 中，則是返回簡單主機名。使用 getCanonicalHostName()` 參數後，在Java 8 和 Java 11 中都能返回完全限定的主機名。
更多詳情參考 PR-7360
https://github.com/apache/pul...
📣 修復 2.6.0 引入的向後兼容問題
PR-5985 破壞了向後兼容性。如果分開運行 Function Worker 與 Broker，Function Worker 和 broker 從 2.5 版本單獨更新到 2.6 版本時會發生以下錯誤：
textjava.lang.NullPointerException: null\n\tat java.net.URI$Parser.parse(URI.java:3104) ~[?:?]java.net.URI.<init>(URI.java:600) ~[?:?]\n\tat java.net.URI.create(URI.java:881) ~[?:?]org.apache.pulsar.functions.worker.WorkerUtils.initializeDlogNamespace(WorkerUtils.java:160) ~[org.apache.pulsar-pulsar-functions-worker-2.7.0-SNAPSHOT.jar:2.7.0-SNAPSHOT]org.apache.pulsar.functions.worker.Worker.initialize(Worker.java:155) ~[org.apache.pulsar-pulsar-functions-worker-2.7.0-SNAPSHOT.jar:2.7.0-SNAPSHOT] org.apache.pulsar.functions.worker.Worker.start(Worker.java:69) ~[org.apache.pulsar-pulsar-functions-worker-2.7.0-SNAPSHOT.jar:2.7.0-SNAPSHOT] org.apache.pulsar.functions.worker.FunctionWorkerStarter.main(FunctionWorkerStarter.java:67) [org.apache.pulsar-pulsar-functions-worker-2.7.0-SNAPSHOT.jar:2.7.0-SNAPSHOT]
錯誤原因：2.5 版本中 broker 會對包含 bookkeeperMetadataServiceUri 欄位的請求做出響應，管理客戶端將返回該欄位為 null，從而導致 NPE。
在 2.6.1 版本中，當初始化 function worker 時，對 BookkeeperMetadataServiceUri 的 value 進行檢查，判斷其是否為 null。
更多詳情參考 PR-7528：https://github.com/apache/pul...。
Pulsar Perf 相關改進📣 在 pulsar-perf 的 producer/consumer/reader 中支持 tlsAllowInsecureConnection在命令行工具 pulsar-perf 中支持 tlsAllowInsecureConnection 配置，以支持對不安全的 TLS 連接的集群進行 producer/consumer/reader 的性能測試。
更多詳情參考 PR-7300：https://github.com/apache/pul...。
參考信息