PIP-187 Add API to analyse a subscription backlog and provide a accurate value
Hello,
this is a PIP to implement a tool to analyse the subscription backlog
Link: https://github.com/apache/pulsar/issues/16597
Prototype: https://github.com/apache/pulsar/pull/16545
Below you can find the proposal (I will amend the GH issue while we
discuss, as usual)
Enrico
Motivation
Currently there is no way to have a accurate backlog for a subscription:
you have only the number of "entries", not messages
server side filters (PIP-105) may filter out some messages
Having the number of entries is sometimes not enough because with
batch messages the amount of work on the Consumers is proportional to
the number of messages, that may vary from entry to entry.
Goal
The idea of this patch is to provide a dedicate API (REST,
pulsar-admin, and Java PulsarAdmin) to "analise" a subscription and
provide detailed information about that is expected to be delivered to
Consumers.
The operation will be quite expensive because we have to load the
messages from storage and pass them to the filters, but due to the
dynamic nature of Pulsar subscriptions there is no other way to have
this value.
One good strategy to do monitoring/alerting is to setup alerts on the
usual "stats" and use this new API to inspect the subscription deeper,
typically be issuing a manual command.
API Changes
internal ManagedCursor API:
CompletableFuture scan(Predicate condition, long
maxEntries, long timeOutMs);
This method scans the Cursor from the lastMarkDelete position to the tail.
There is a time limit and a maxEntries limit, these are needed in
order to prevent huge (and useless) scans.
The Predicate can stop the scan, if it doesn't want to continue the
processing for some reasons.
New REST API:
@GET
@Path("/{tenant}/{namespace}/{topic}/subscription/{subName}/analiseBacklog")
@ApiOperation(value = "Analyse a subscription, by scanning all the
unprocessed messages")
public void analiseSubscriptionBacklog(
@Suspended final AsyncResponse asyncResponse,
@ApiParam(value = "Specify the tenant", required = true)
@PathParam("tenant") String tenant,
@ApiParam(value = "Specify the namespace", required = true)
@PathParam("namespace") String namespace,
@ApiParam(value = "Specify topic name", required = true)
@PathParam("topic") @Encoded String encodedTopic,
@ApiParam(value = "Subscription", required = true)
@PathParam("subName") String encodedSubName,
@ApiParam(value = "Is authentication required to perform
this operation")
@QueryParam("authoritative") @DefaultValue("false")
boolean authoritative) {
API response model:
public class AnaliseSubscriptionBacklogResult {
private long entries;
private long messages;
private long filterRejectedEntries;
private long filterAcceptedEntries;
private long filterRescheduledEntries;
private long filterRejectedMessages;
private long filterAcceptedMessages;
private long filterRescheduledMessages;
private boolean aborted;
The response contains "aborted=true" is the request has been aborted
by some internal limitations, like a timeout or the scan hit the max
number of entries.
We are not going to provide more details about the reason of the stop.
It will make the API too detailed and harder to maintain. Also, in the
logs of the broker you will find the details.
New PulsarAdmin API:
/**
* Analise subscription backlog.
* This is a potentially expensive operation, as it requires
* to read the messages from storage.
* This function takes into consideration batch messages
* and also Subscription filters.
* @param topic
*Topic name
* @param subscriptionName
*the subscription
* @return an accurate analysis of the backlog
* @throws PulsarAdminException
*Unexpected error
*/
AnaliseSubscriptionBacklogResult analiseSubscriptionBacklog(String
topic, String subscriptionName)
throws PulsarAdminException;
/**
* Analise subscription backlog.
* This is a potentially expensive operation, as it requires
* to read the messages from storage.
* This function takes into consideration batch messages
* and also Subscription filters.
* @param topic
*Topic name
* @param subscriptionName
*the subscription
* @return an accurate analysis of the backlog
* @throws PulsarAdminException
*Unexpected error
*/
CompletableFuture
analiseSubscriptionBacklogAsync(String topic,
String subscriptionName);
A pulsar-admin command will be added as well as usual.
New configuration entries in broker.conf:
@FieldContext(
category = CATEGORY_POLICIES,
doc = "Maximum time to spend while scanning a subscription to
calculate the accurate backlog"
)
private long subscriptionBacklogScanMaxTimeMs = 1000 * 60 *
Re: [VOTE] Enable GitHub Discussion for user-facing discussion
+1 Thanks, Haiting On 2022/07/12 10:00:27 tison wrote: > Hi, > > In the previous email[1] I started a discussion about enabling GitHub > Discussions in apache/pulsar repository and we meet a consensus to avoid > making development discussions truth happen on the sources. It's also a > requirement of INFRA team[2] > > Apart of it, for user-facing discussions it's conventions for Pulsar users > who have a GitHub account but are unfamiliar with mailing list to throw > their use case and questions on GitHub discussion. > > Dave has opened and issue[2][3] and prepare the patch[4] for turning on the > discussion option but obviously we still need an explicit consensus among > the community and it's also required before INFRA team takes action. > > I'd like to start this voting thread for "Enable GitHub Discussion for > user-facing discussion", please reply with your opinion: > > [ ] +1 approve > [ ] +0 no opinion > [ ] -1 disapprove (and reason why) > > Best, > tison. > > [1] https://lists.apache.org/thread/1y7zbchlbokwnpd0jv2tt5jtzg6px6yn > [2] https://issues.apache.org/jira/browse/INFRA-23477 > [3] https://github.com/apache/pulsar/issues/16275 > [4] https://github.com/apache/pulsar/pull/16528 >
[Announcement] Pulsar Summit 2022 is coming soon!
Hi team, The Pulsar Summit 2022 will be held on August 18th at Hotel Nikko in San Francisco. This action-packed, one-day event will include amazing sessions with speakers from AWS, Klaviyo, Ververica, OneHouse, Nomura, the Apache Pulsar PMC members, and more! Find the full agenda here [1]. In addition to amazing speakers and content, there will be a ton of networking opportunities. This is the first-ever in-person Pulsar Summit in North America. It's a great opportunity to connect with the community and to learn the latest in real-time data streaming. Don't miss this chance to be part of the great event! Save your spot today! Best, Yu [1] https://pulsar-summit.org/event/san-francisco-2022
[GitHub] [pulsar-helm-chart] pgier commented on issue #265: Release tag pulsar-2.9.3 is not matching the images version in values.yaml
pgier commented on issue #265: URL: https://github.com/apache/pulsar-helm-chart/issues/265#issuecomment-1184585656 If you look at the `app version` of the 2.9.3 release of the Helm chart, you can see that it still points to version 2.9.2 of Pulsar. However, I agree with you, that it would be nice if these versions were kept in sync. So in this case it probably would have been better to use a version something like `2.9.2_1` to make it more obvious which version of Pulsar this release uses, especially considering that there will likely be a 2.9.3 release of Pulsar soon. @sijie @michaeljmarshall WDYT, can we keep future releases of the Helm chart synced to the Pulsar version, and use an optional build/patch number to indicate that something was fixed in the chart? -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: dev-unsubscr...@pulsar.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
Re: [DISCUSS] PIP-184: Cluster migration or Blue-Green cluster deployment support in Pulsar
Hi Rajan, Just a note that 184 was already taken by https://github.com/apache/pulsar/issues/16481 - Dave On Tue, Jul 12, 2022 at 6:23 PM Rajan Dhabalia wrote: > Hi, > > We have created PIP-184 which helps users to perform cluster migration with > Apache Pulsar. Cluster migration or Blue-Green cluster deployment is one of > the proven solutions to migrate live traffic from one cluster to another. > One of the examples is applications running on Kubernetes sometimes require > a Kubernetes cluster upgrade which can cause downtime for the entire > application during a Kubernetes cluster upgrade. Blue-green deployment is > an application release model that gradually transfers user traffic from a > previous version of an app or microservice to a nearly identical new > release—both of which are running in production. > > The old version can be called the blue environment while the new version > can be known as the green environment. Once production traffic is fully > transferred from blue to green, blue can standby in case of rollback or be > pulled from production and updated to become the template upon which the > next update is made. We need such capability in Apache pulsar to migrate > live traffic from the blue cluster to the green cluster so, eventually, the > entire traffic moves from the blue cluster to the green cluster without > causing downtime for the topics. > > PIP: https://github.com/apache/pulsar/issues/16551 > > Thanks, > Rajan >
Re: [DISCUSS] PIP-186: Introduce two phase deletion protocol based on system topic
This is very interesting.
I have only one concern.
I think that we should at least use a per-tenant system topic, or,
better, per-namespace.
There is no need to create the deletion topic if there is nothing to delete.
I am used to dealing with Pulsar clusters in which Tenants are
strictly isolated.
Introducing another component that is not tenant aware it kind of a
problem (we already have such problem with the Transaction
Coordinator)
Enrico
Il giorno mer 13 lug 2022 alle ore 10:54 horizonzy
ha scritto:
>
> Hi Pulsar community: I open a pip to discuss "Introduce two phase deletion
> protocol based on system topic" Proposal Link:
> https://github.com/apache/pulsar/issues/16569
>
> ---
>
> ## Motivation
> Original issue: #13238
> In current ledger deletion, we divided it into two separate steps. It
> happens in ManagedLedger and ManagedCursor.
> Remove all the waiting to delete ledgers from the ledger list and update
> the newest ledger list into a meta store.
> In the meta store update callback operation, delete the waiting to delete
> ledgers from storage systems, such as BookKeeper or Tiered storage.
>
> Due to the separate step, we can’t ensure the ledger deletion transaction.
> If the first step succeeds and the second step fails, it will lead to
> ledgers that can't be deleted from the storage system forever. The second
> step may fail by broker restart or storage system deletion failed.
>
> In our customer’s environment, we have found many orphan ledgers cause by
> the above reason.
> ## Design
> Based on the above, we Introduce LedgerDeletionService to support two phase
> deletion. We hope it provides a general solution for two phase deletion. It
> will cover the problem we already found in managed-ledger, managed-cursor
> and schema-storage.
>
> In this design, we use the system topic to help us to store the pending
> delete ledger.
> * pulsar/system/persistent/__ledger_deletion : store the pending delete
> ledger
> * pulsar/system/persistent/__ledger_deletion_archive : as the DLQ for above
>
>
> ### The first phase:
> ```
> client.newProducer(Schema.AVRO(PendingDeleteLedgerInfo.class))
> .topic("pulsar/system/persistent/__ledger_deletion")
> .enableBatching(false)
> .createAsync();
> ```
> In the LedgerDeletionService start, it will create a producer to send
> pending delete ledger.
> When delete a ledger, a PendingDeleteLedgerInfo msg with 1 min delay (the
> delay is for consumer side, if send it immediately, maybe the metadata
> din't change when consumer receive it). After the send operation succeeds,
> then to operate metadata. If send msg failed, we think this deletion
> operation failed, and didn't operate metadata.
>
> **PendingDeleteLedgerInfo**
> ```
> public class PendingDeleteLedgerInfo {
> /**
> * Partitioned topic name without domain. Likes
> public/default/test-topic-partition-1 or
> * public/default/test-topic
> */
> private String topicName;
>
> /**
> * The ledger component . managed-ledger, managed-cursor and
> schema-storage.
> */
> private LedgerComponent ledgerComponent;
>
> /**
> * The ledger type. ledger or offload-ledger.
> */
> private LedgerType ledgerType;
>
> /**
> * LedgerId.
> */
> private Long ledgerId;
>
> /**
> * Context, holds offload info. If bk ledger, the context is null.
> */
> private MLDataFormats.ManagedLedgerInfo.LedgerInfo context;
>
> /**
> * When a consumer receives a pending delete ledger, maybe the ledger
> is still in use, we need to check the ledger is in use.
> * In some cases, we needn't check the ledger still in use.
> */
> private boolean checkLedgerStillInUse;
>
> /**
> * Extent properties.
> */
> private Map properties = new HashMap<>();
> }
> ```
> ### The second phase
> ```
> client.newConsumer(Schema.AVRO(PendingDeleteLedgerInfo.class))
> .topic("pulsar/system/persistent/__ledger_deletion")
> .subscriptionName("ledger-deletion-worker")
> .subscriptionType(SubscriptionType.Shared)
> .deadLetterPolicy(DeadLetterPolicy.builder()
>
>
> .deadLetterTopic(SystemTopicNames.LEDGER_DELETION_ARCHIVE_TOPIC.getPartitionedTopicName())
> .maxRedeliverCount(10).build())
> .subscribeAsync()
> ```
> In the LedgerDeletionService start, it will start a consumer to consume
> pending delete ledger.
>
> ### Check if the ledger is still in use
> When received a pending delete ledger, we should check if the pending
> delete ledger still exists in the metadata. If exists, we should give up to
> delete this ledger in this time, the consumer won't ack this message, do
> reconsumeLater 10 min. If it does not exist, it will try to delete legder
> or offload-ledger according to the ledger-type. If delete succeeds, ack
> this message, if delete failed, reconsumerLater 10 min. If a
> PendingDeleteLedger msg reconsume reach 10, the msg will transfer to DLQ
> pulsar/system/persistent/__ledger_deletion_archive
>
> _Tip
Re: [DISCUSS] PIP-184: Cluster migration or Blue-Green cluster deployment support in Pulsar
On Thu, Jul 14, 2022 at 8:29 AM Dave Maughan wrote: > Hi Rajan, > > Just a note that 184 was already taken by > https://github.com/apache/pulsar/issues/16481 > >>> Sure, I have renamed it as PIP-188 and updated the wiki: https://github.com/apache/pulsar/wiki - Dave > > > On Tue, Jul 12, 2022 at 6:23 PM Rajan Dhabalia > wrote: > > > Hi, > > > > We have created PIP-184 which helps users to perform cluster migration > with > > Apache Pulsar. Cluster migration or Blue-Green cluster deployment is one > of > > the proven solutions to migrate live traffic from one cluster to another. > > One of the examples is applications running on Kubernetes sometimes > require > > a Kubernetes cluster upgrade which can cause downtime for the entire > > application during a Kubernetes cluster upgrade. Blue-green deployment is > > an application release model that gradually transfers user traffic from a > > previous version of an app or microservice to a nearly identical new > > release—both of which are running in production. > > > > The old version can be called the blue environment while the new version > > can be known as the green environment. Once production traffic is fully > > transferred from blue to green, blue can standby in case of rollback or > be > > pulled from production and updated to become the template upon which the > > next update is made. We need such capability in Apache pulsar to migrate > > live traffic from the blue cluster to the green cluster so, eventually, > the > > entire traffic moves from the blue cluster to the green cluster without > > causing downtime for the topics. > > > > PIP: https://github.com/apache/pulsar/issues/16551 > > > > Thanks, > > Rajan > > >
Re: [DISCUSS] PIP-184: Cluster migration or Blue-Green cluster deployment support in Pulsar
>
> No, as it's mentioned in PIP: this API will terminate the topic so, it will
> not allow any new write and producers on that topic, and then it flags the
> topic as migrated and finally it sends migrated-topic response to
> producers/caught-up consumers(with 0 backlog) for further redirection.
So, this method will complete once "termination" of topic is complete: wait
for all producers to disconnect, wait for consumers to finish backlog and
then all disconnect?
This flag is to persist the state of managed-ledger that it's considered
> for migration so, if a broker crashes then it knows about the
> managed-ledger state.
>
So perhaps the flag means "migrationInProgress" or "migrationStarted"?
On Wed, Jul 13, 2022 at 7:23 PM Rajan Dhabalia wrote:
> On Wed, Jul 13, 2022 at 1:55 AM Asaf Mesika wrote:
>
> > Few questions
> >
> > "CompletableFuture asyncMigrate();"
> > Does this method only change the status of the managed ledger?
> >
> No, as it's mentioned in PIP: this API will terminate the topic so, it will
> not allow any new write and producers on that topic, and then it flags the
> topic as migrated and finally it sends migrated-topic response to
> producers/caught-up consumers(with 0 backlog) for further redirection.
>
> >
> > "message ManagedLedgerInfo {
> >
> >// Flag to check if topic is terminated and migrated to different
> > cluster
> >optional bool migrated = 4;
> >
> > }"
> >
> > This flag then is only changed to true when it has finished migration:
> i.e.
> > no new messages were written, all existing consumers finished reading all
> > messages and disconnected and the topic can now be deleted?
> >
> This flag is to persist the state of managed-ledger that it's considered
> for migration so, if a broker crashes then it knows about the
> managed-ledger state.
>
>
> > "Broker sends topic migration message to client so, producer/consumer at
> > client side can handle redirection accordingly"
> >
> > For producers, the message will be sent the moment the status of the
> topic
> > has changed, so all messages from there on will be written to the new
> > cluster?
> >
> Yes.
>
>
> > For consumers, the message will be sent when there are no more messages
> to
> > read?
> >
> Yes.
>
> >
> >
> >
> > On Tue, Jul 12, 2022 at 8:23 PM Rajan Dhabalia
> > wrote:
> >
> > > Hi,
> > >
> > > We have created PIP-184 which helps users to perform cluster migration
> > with
> > > Apache Pulsar. Cluster migration or Blue-Green cluster deployment is
> one
> > of
> > > the proven solutions to migrate live traffic from one cluster to
> another.
> > > One of the examples is applications running on Kubernetes sometimes
> > require
> > > a Kubernetes cluster upgrade which can cause downtime for the entire
> > > application during a Kubernetes cluster upgrade. Blue-green deployment
> is
> > > an application release model that gradually transfers user traffic
> from a
> > > previous version of an app or microservice to a nearly identical new
> > > release—both of which are running in production.
> > >
> > > The old version can be called the blue environment while the new
> version
> > > can be known as the green environment. Once production traffic is fully
> > > transferred from blue to green, blue can standby in case of rollback or
> > be
> > > pulled from production and updated to become the template upon which
> the
> > > next update is made. We need such capability in Apache pulsar to
> migrate
> > > live traffic from the blue cluster to the green cluster so, eventually,
> > the
> > > entire traffic moves from the blue cluster to the green cluster without
> > > causing downtime for the topics.
> > >
> > > PIP: https://github.com/apache/pulsar/issues/16551
> > >
> > > Thanks,
> > > Rajan
> > >
> >
>
Re: [DISCUSS] PIP-184: Cluster migration or Blue-Green cluster deployment support in Pulsar
On Thu, Jul 14, 2022 at 9:59 AM Asaf Mesika wrote:
> >
> > No, as it's mentioned in PIP: this API will terminate the topic so, it
> will
> > not allow any new write and producers on that topic, and then it flags
> the
> > topic as migrated and finally it sends migrated-topic response to
> > producers/caught-up consumers(with 0 backlog) for further redirection.
>
> So, this method will complete once "termination" of topic is complete: wait
> for all producers to disconnect, wait for consumers to finish backlog and
> then all disconnect?
>
>> Producer can be immediately disconnected and allowed to redirect to
green cluster as soon as topic is terminated and marked as part of
termination. (considering the topic doesn't have geo-replication enabled.
For geo-replicated topics , you can read "Replicator and message ordering
handling" section in PIP).
>
> This flag is to persist the state of managed-ledger that it's considered
> > for migration so, if a broker crashes then it knows about the
> > managed-ledger state.
> >
>
So perhaps the flag means "migrationInProgress" or "migrationStarted"?
>
>> It's just a state to mark that broker has considered it for migration
similar to the Terminated state. we don't need extra state for completion
because the broker is going to delete the topic once all subscribers reach
the end of the topic.
>
> On Wed, Jul 13, 2022 at 7:23 PM Rajan Dhabalia
> wrote:
>
> > On Wed, Jul 13, 2022 at 1:55 AM Asaf Mesika
> wrote:
> >
> > > Few questions
> > >
> > > "CompletableFuture asyncMigrate();"
> > > Does this method only change the status of the managed ledger?
> > >
> > No, as it's mentioned in PIP: this API will terminate the topic so, it
> will
> > not allow any new write and producers on that topic, and then it flags
> the
> > topic as migrated and finally it sends migrated-topic response to
> > producers/caught-up consumers(with 0 backlog) for further redirection.
> >
> > >
> > > "message ManagedLedgerInfo {
> > >
> > >// Flag to check if topic is terminated and migrated to different
> > > cluster
> > >optional bool migrated = 4;
> > >
> > > }"
> > >
> > > This flag then is only changed to true when it has finished migration:
> > i.e.
> > > no new messages were written, all existing consumers finished reading
> all
> > > messages and disconnected and the topic can now be deleted?
> > >
> > This flag is to persist the state of managed-ledger that it's considered
> > for migration so, if a broker crashes then it knows about the
> > managed-ledger state.
> >
> >
> > > "Broker sends topic migration message to client so, producer/consumer
> at
> > > client side can handle redirection accordingly"
> > >
> > > For producers, the message will be sent the moment the status of the
> > topic
> > > has changed, so all messages from there on will be written to the new
> > > cluster?
> > >
> > Yes.
> >
> >
> > > For consumers, the message will be sent when there are no more messages
> > to
> > > read?
> > >
> > Yes.
> >
> > >
> > >
> > >
> > > On Tue, Jul 12, 2022 at 8:23 PM Rajan Dhabalia
> > > wrote:
> > >
> > > > Hi,
> > > >
> > > > We have created PIP-184 which helps users to perform cluster
> migration
> > > with
> > > > Apache Pulsar. Cluster migration or Blue-Green cluster deployment is
> > one
> > > of
> > > > the proven solutions to migrate live traffic from one cluster to
> > another.
> > > > One of the examples is applications running on Kubernetes sometimes
> > > require
> > > > a Kubernetes cluster upgrade which can cause downtime for the entire
> > > > application during a Kubernetes cluster upgrade. Blue-green
> deployment
> > is
> > > > an application release model that gradually transfers user traffic
> > from a
> > > > previous version of an app or microservice to a nearly identical new
> > > > release—both of which are running in production.
> > > >
> > > > The old version can be called the blue environment while the new
> > version
> > > > can be known as the green environment. Once production traffic is
> fully
> > > > transferred from blue to green, blue can standby in case of rollback
> or
> > > be
> > > > pulled from production and updated to become the template upon which
> > the
> > > > next update is made. We need such capability in Apache pulsar to
> > migrate
> > > > live traffic from the blue cluster to the green cluster so,
> eventually,
> > > the
> > > > entire traffic moves from the blue cluster to the green cluster
> without
> > > > causing downtime for the topics.
> > > >
> > > > PIP: https://github.com/apache/pulsar/issues/16551
> > > >
> > > > Thanks,
> > > > Rajan
> > > >
> > >
> >
>
Re: [DISCUSS] PIP-186: Introduce two phase deletion protocol based on system topic
If we use per-tenant system topic or per-namespace. and there is no active topic in the tenant anymore, how we consume the msg in this tenant. This is the concern I cared about, so I prefer to use system topic.
Re: [VOTE] Pulsar Release 2.9.3 Candidate 2
Thank you all, Close the vote with 3 (+1) bindings, and 4 (+1) non-bindings. I will continue the release process. On Thu, 14 Jul 2022 at 13:05, Michael Marshall wrote: > +1 (non-binding) > > - Verified signatures for all 48 artifacts > - Verified sha512 checksums for all 48 artifacts > - Verified rat check by running mvn apache-rat:check > - Compiled from sources using JDK 11 and running mvn clean install > -DskipTests > - Inspected docker image mattison/pulsar:2.9.3-rc-2 using `dive` > - Deployed a test cluster to EKS using mattison/pulsar:2.9.3-rc-2 > docker image to verify the integration of many components using the > DataStax Pulsar Helm Chart > > Thank you for managing the release Mattison Chao! > > Thanks, > Michael > > > > > > On Wed, Jul 13, 2022 at 10:12 PM guo jiwei wrote: > > > > +1 (non-binding) > > > > - Download links are valid. > > - Checksums and signatures. > > - LICENSE/NOTICE/exist > > - Rat check passes > > - Compile source with JDK11 > > - Run standalone, and run pulsar produce/consume > > > > > > Regards > > Jiwei Guo (Tboy) > > > > > > On Wed, Jul 13, 2022 at 11:24 PM Hang Chen wrote: > > > > > +1 (binding) > > > > > > - Checked the checksum and license > > > - Build from source code with JDK 11 > > > - Run standalone, and run pulsar-perf produce/consume > > > - Verified pulsar-io-lakehouse connector > > > > > > Thanks, > > > Hang > > > > > > PengHui Li 于2022年7月8日周五 23:01写道： > > > > > > > > +1 binding > > > > > > > > - checked the signature > > > > - run standalone and test produce/consume > > > > - verified function and stateful function > > > > - verified the Cassandra connector > > > > > > > > Thanks, > > > > Penghui > > > > > > > > On Fri, Jul 8, 2022 at 8:16 PM Nicolò Boschi > > > wrote: > > > > > > > > > +1 (non binding) > > > > > > > > > > Checks: > > > > > - Checksum and signatures > > > > > - Apache Rat check passes > > > > > - Compile from source w JDK11 > > > > > - Build docker image from source > > > > > - Run Pulsar standalone and produce-consume from CLI > > > > > > > > > > Thank you! > > > > > > > > > > Nicolò Boschi > > > > > > > > > > > > > > > Il giorno ven 8 lug 2022 alle ore 13:47 Qiang Huang < > > > > > qiang.huang1...@gmail.com> ha scritto: > > > > > > > > > > > +1 > > > > > > > > > > > > Enrico Olivelli 于2022年7月8日周五 19:42写道： > > > > > > > > > > > > > +1 (binding) > > > > > > > - built from sources, with JDK11, run a couple of smoke tests > > > > > > > - verified RAT > > > > > > > - verified checksums and signatures > > > > > > > - run some JMS tests using Transactions (the JMS library > bundles > > > > > > > 2.10.x Java client) > > > > > > > > > > > > > > Thanks for driving the release! > > > > > > > > > > > > > > Enrico > > > > > > > > > > > > > > Enrico > > > > > > > > > > > > > > Il giorno mer 6 lug 2022 alle ore 10:26 mattison chao > > > > > > > ha scritto: > > > > > > > > > > > > > > > > This is the second release candidate for Apache Pulsar, > version > > > > > 2.9.3. > > > > > > > > > > > > > > > > It fixes the following issues: > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > https://github.com/apache/pulsar/pulls?q=is%3Amerged+is%3Apr+label%3Arelease%2F2.9.3+ > > > > > > > < > > > > > > > > > > > > > > > > > > > > > > https://github.com/apache/pulsar/pulls?q=is%3Amerged+is%3Apr+label%3Arelease%2F2.9.3+ > > > > > > > > > > > > > > > > > > > > > > > > *** Please download, test and vote on this release. This vote > > > will > > > > > stay > > > > > > > open > > > > > > > > for at least 72 hours *** > > > > > > > > > > > > > > > > Note that we are voting upon the source (tag), binaries are > > > provided > > > > > > for > > > > > > > > convenience. > > > > > > > > > > > > > > > > Source and binary files: > > > > > > > > > > > > > > > > > > > > > > > > > > https://dist.apache.org/repos/dist/dev/pulsar/pulsar-2.9.3-candidate-2/ > > > > > > > > > > > > > > > > SHA-512 checksums: > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > 291eb3f9da234cf38fcd02de781def9a9354025bb4f98c78b160935a6a9c6721cc8280d80b93049656ee5a20e36ddc5d3446b7b034405c07d447833ff65e > > > > > > > ./apache-pulsar-2.9.3-bin.tar.gz > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > d57fa3c8eae1f3ba60422a56288c99a472a671295e41573c884a9d9a71b5fcf622782732e9cfd5128e1b92304b3812cc877675384ac0dbc78109d7efb23681f4 > > > > > > > ./apache-pulsar-2.9.3-src.tar.gz > > > > > > > > > > > > > > > > Maven staging repo: > > > > > > > > > > > > > > > > > > https://repository.apache.org/content/repositories/orgapachepulsar-1163/ > > > > > > > > > > > > > > > > The tag to be voted upon: > > > > > > > > v2.9.3-candidate-2 (dd9a5f1f91651b634600f66c53dcc6ad855fb669) > > > > > > > > > > > > > > > > > https://github.com/apache/pulsar/releases/tag/v2.9.3-candidate-2 > > > > > > > > > > > > > > > > The docker images: > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > https://hub.docker.com/layers/248117318/mattison/pu
