Re: [VOTE] Release Apache RocketMQ Exporter 0.0.2

[heng du]

+1
I checked:
check LICENSE, should be Apache V2
check NOTICE, should have a notice for third-party dependency if necessary
Hash and Tag in GitHub repo is matching the current artifacts


jinrongtong  于2024年2月13日周二 18:10写道：

> +1, I checked[OK]  Checksums and PGP signatures are valid for Source
> package.[OK]  Hash and Tag in GitHub repo is matching the current
> artifacts.In addition, it would be better to update the copyright year
> in the notice file during the next release.
> At 2024-02-13 17:53:29, "Gaoyang Cai"  wrote:
> >Hello RocketMQ Community,
> >
> >This is the vote for 0.0.2 RC1 of Apache RocketMQ Exporter.
> >
> >This is the first formal release for Apache RocketMQ Exporter. All
> changes since supporting Apache RocketMQ 4.x are included, as well as those
> making it compatible to Apache RocketMQ 5.x. The group id of maven has been
> modified according to guidelines of ASF.
> >
> >
> >The artifacts:
> >
> https://dist.apache.org/repos/dist/dev/rocketmq/rocketmq-exporter/0.0.2-rc1/
> >
> >The staging repo:
> >
> https://repository.apache.org/content/repositories/orgapacherocketmq-1304/
> >
> >Git tag and release notes for the release:
> >
> https://github.com/apache/rocketmq-exporter/releases/tag/rocketmq-exporter-0.0.2
> >
> >Hash for the release tag:
> >696f346f5a18396fe8074611981e77338a16af41
> >
> >The artifacts have been signed with Key:
> >D45CD805DE178E32B8427AD5E14A98593C6E6037 , which can be found in the keys
> file:  https://dist.apache.org/repos/dist/dev/rocketmq/KEYS
> >
> >Checklist for reference:
> >Note that this is not an official policy but may help with checking
> releases.
> >
> >Fill in the following:
> >[ ]  check LICENSE, should be Apache V2
> >[ ]  check NOTICE, should have a notice for third-party dependency if
> necessary
> >[ ]  extract the zip and check if the source version is correct
> >[ ]  verify the asc(PGP sign),SHA512 and docker image is correct
> >[ ]  build the source, start exporter according to the quick-start
> >
> >The vote will be open for at least 72 hours or until the necessary number
> of votes are reached.
> >Please vote accordingly:
> >
> >[ ] +1 approve
> >
> >[ ] +0 no opinion
> >
> >[ ] -1 disapprove with the reason
> >
> >Thanks
> >The Apache RocketMQ Team
>

Re: [VOTE][RIP-62]Coldreadcontrol

[heng du]

+1

2017赵科 <464473...@qq.com.invalid> 于2023年3月14日周二 10:17写道：

> Hi, SSpirits
>
>
> Thank you very much for your reply, wish you a good mood every day.
>
>
> Best Regards!
> drizzle.zk
>
>
>
> 2017赵科
> 464473...@qq.com
>
>
>
> 
>
>
>
>
> --原始邮件--
> 发件人:
>   "dev"
>
>  发送时间:2023年3月9日(星期四) 上午10:04
> 收件人:"dev" dev@rocketmq.apache.org;
>
> 主题:Re: [VOTE][RIP-62]Coldreadcontrol
>
>
>
> Hi 赵科,
>
> Currently, RocketMQ uses mincore system call to determine if the message
> data is in memory or swapped out. It seems more reliable than judging hot
> and cold data based on the maintenance experience described in your
> proposal. And turning off read-ahead for old CommitLog is a good idea,
> looking forward to your progress!
>
> Your response would be highly appreciated.
> SSpirits
> Email：ad...@lv5.moe On 7 Mar 2023 at 2:55 PM +0800, 2017赵科 <464473...@qq.com.INVALID,
> wrote:
> Hi, RocketMQ Community,
>
>
> As discussed in the previous email, we launched a new RIP​​[RIP-62] Cold
> read control to support this feature. Now thenbsp;i...@foxmail.com
> nbsp;is willing to support the RIP, so I think it is time to start an
> email thread to enter the voting process.
>
>
> The vote will be open for at least 72 hours or until a necessary number of
> votes are reached.
>
>
> Please vote accordingly:
>
>
> [ ] +1 approve
> [ ] +0 no opinion
> [ ] -1 disapprove with the reason
>
>
> Best Regards!
> drizzle.zk
>
>
>
>
> links:
> Google Doc:nbsp;
> https://docs.google.com/document/d/1P8JPX5b9CwYMlaFi_UBxqwxFoIiOXWuAEjV4yWdfFUw/edit?usp=sharing
>
>
>
>
>
>
>
>
> 2017赵科
> 464473...@qq.com
>
>
>
> nbsp;

Re: [VOTE][RIP-50]RocketMQ Transaction Message Improvement

[heng du]

+1

Xinyu Zhou  于2022年10月18日周二 10:05写道：

> +1
>
> Thanks for this RIP!
>
> On Mon, Oct 17, 2022 at 6:51 PM tihong ruan  wrote:
>
> > As discussed in the previous email, we discussed RocketMQ Transaction
> > Message Improvement, and it's time to start an email thread to enter the
> > voting process.
> >
> > Links:
> >
> >
> https://github.com/apache/rocketmq/wiki/RIP-50-RocketMQ-Transaction-Message-Improvement
> >
> > The vote will be open for at least 72 hours or until a necessary number
> of
> > votes is reached.
> >
>

Re: [VOTE][RIP-46] Observability improvement for RocketMQ

[heng du]

+1

Xinyu Zhou  于2022年9月27日周二 16:43写道：

> +1
>
> On Tue, Sep 27, 2022 at 2:36 PM aaron ai  wrote:
>
> > +1, Looking forward to the follow-up pull request.
> >
> > SSpirits  于2022年9月27日周二 14:29写道：
> >
> > > As discussed in the previous email, we discussed adding native metrics
> > for
> > > RocketMQ, and it's time to start an email thread to enter the voting
> > > process.
> > >
> > > Links:
> > > https://shimo.im/docs/m4kML2VzdESO9eqD
> > >
> > > The vote will be open for at least 72 hours or until a necessary number
> > of
> > > votes is reached.
> > >
> > > SSpirits
> > > Email：ad...@lv5.moe
> > >
> >
>

Re: 回复: [DISCUSS][RIP-46] Observability improvement for RocketMQ

[heng du]

+1 for vote

Hu Zongtang  于2022年9月27日周二 11:40写道：

> Okay, I see it!
> I don't have other question!
> 
> 发件人: Xinyu Zhou 
> 发送时间: 2022年9月27日 10:52
> 收件人: dev@rocketmq.apache.org 
> 主题: Re: 回复: [DISCUSS][RIP-46] Observability improvement for RocketMQ
>
> Hello Zongtang,
>
> About you mentioned two questions, this RIP will cover the first one. For
> the second one, it seems to be an issue about deployment, we can create a
> new thread to discuss it.
>
> And, let's keep the discussion on the mailing list AFAP. Of course,
> the online meeting is an effective complement. But, remember that any
> conclusion must be reached on the mailing list.
>
> Regards
>
> On Mon, Sep 26, 2022 at 7:11 PM Hu Zongtang 
> wrote:
>
> > Maybe, we can discuss the qustion two which I metioned above in next
> > online meeting of apache rocketmq commnity and draft another RIP for this
> > feature! @sspirits @lizhanhui@duheng;
> > 
> > 发件人: SSpirits 
> > 发送时间: 2022年9月26日 16:16
> > 收件人: dev@rocketmq.apache.org 
> > 主题: Re: 回复: [DISCUSS][RIP-46] Observability improvement for RocketMQ
> >
> > This RIP is aimed to implement out-of-box metrics for broker and proxy.
> > The metrics specification will adhere to OpenTelemetry standards and is
> > compatible with legacy solutions such as rocketmq-exporter and
> Prometheus.
> > And we should discuss the specification and other details in this mail
> list
> > or GitHub issues.
> >
> > Your response would be highly appreciated.
> > SSpirits
> > Email：ad...@lv5.moe
> > 在 2022年9月26日 +0800 15:58，Hu Zongtang ，写道：
> > I look your desgin document of RIP-46 and have some serveral questions
> > below:
> >
> > (1)Actually, this RIP is based on the rocketmq-exporter and Prometheus,
> > will you work focus on the metrics collector and specification of metric?
> > (2)And I suggest you can implment the elasticity of broker and proxy pod
> > in the k8s cluster base on the some other component, such as HPA; And we
> > can disscuss about this part in online meeting of Apache rocketmq!
> >
> > 
> > 发件人: SSpirits 
> > 发送时间: 2022年9月26日 13:38
> > 收件人: dev@rocketmq.apache.org 
> > 主题: [DISCUSS][RIP-46] Observability improvement for RocketMQ
> >
> > Hi, RocketMQ Community：
> >
> > We have a plan to improve the observability of RocketMQ. Specifically, we
> > hope to introduce native metrics for RocketMQ.
> >
> > We have written the proposal, and you can see it by the link below:
> > https://shimo.im/docs/m4kML2VzdESO9eqD
> >
> > Please reply to this email if you have any suggestions.
> >
> > SSpirits
> > Email：ad...@lv5.moe
> >
>

Re: Re:Re:[RESTART][VOTE]Release Apache RocketMQ 5.0.0 RC2

[heng du]

+1
I checked：
[OK]  check LICENSE, should be Apache V2
[OK]  check NOTICE, should have a notice for third-party dependency if
necessary
[OK]  extract the zip and check if the source version is correct
[OK]  verify the asc(PGP sign),SHA512
[OK]  build the source, start nameserver, and broker according to the
quick-start
[OK]  the cluster list version is correct


Gaoyang Cai  于2022年9月20日周二 14:25写道：

>
> +1 (Non-binding)
>
>
> I checked:
>
> [OK]  check LICENSE, should be Apache V2
>
> [OK]  check NOTICE, should have a notice for third-party dependency if
> necessary
>
> [OK]  extract the zip and check if the source version is correct
>
> [OK]  verify the asc(PGP sign),SHA512
>
> [OK]  build the source, start nameserver and broker according to the
> quick-start
>
> [OK]  run clusterList command to see if the version is correct
>
>
>
>
>
>
> At 2022-09-20 09:09:07, "jinrongtong"  wrote:
> >+1, I checked[OK]  extract the zip and check if the source
> version is correct[OK]  verify the asc(PGP
> sign),SHA512[OK]  maven jar in nexus repo is right
> >At 2022-09-19 19:39:25, "hill"  wrote:
> >>Git tag for the release should be updated to
> >>
> >>
> >>
> >>f3e113cb1f98ced8327e7c97bfb5a623950339ef
> >>
> >>
> >>
> >>
> >>At 2022-09-19 13:27:57, "hill"  wrote:
> >>
> >>Hello RocketMQ Community,
> >>
> >>
> >>
> >>
> >>This is the vote for 5.0.0 RC2 of Apache RocketMQ.
> >>
> >>This release is to improve some features and issues for apache
> rocketmq,such as grpc proxy ,batch message,  static topic ，new ha
> architecture ，fix some bugs and issues and so on.
> >>
> >>
> >>
> >>
> >>The artifacts:
> >>
> >>https://dist.apache.org/repos/dist/dev/rocketmq/5.0.0-rc2/
> >>
> >>
> >>
> >>
> >>The staging repo:
> >>
> >>
> https://repository.apache.org/content/repositories/orgapacherocketmq-1100/
> >>
> >>
> >>
> >>
> >>Git tag for the release:
> >>
> >>https://github.com/apache/rocketmq/releases/tag/rocketmq-all-5.0.0
> >>
> >>
> >>
> >>
> >>Hash for the release tag:
> >>
> >>3f7b0fd17be14f15bd12d19afcbea26fa9ee5560
> >>
> >>f3e113cb1f98ced8327e7c97bfb5a623950339ef
> >>
> >>
> >>
> >>
> >>Release Notes:
> >>
> >>https://rocketmq.apache.org/third-blog/2022/09/09/5.0.0/
> >>
> >>
> >>
> >>
> >>The artifacts have been signed with Key :
> >>
> >>D011F2A8C9474A34099477A5C99B3EAC6B119386, which can be found in the keys
> file: https://dist.apache.org/repos/dist/dev/rocketmq/KEYS
> >>
> >>
> >>
> >>
> >>Checklist for reference,
> >>
> >>Note that this is not an official policy but may help with checking
> releases.
> >>
> >>
> >>
> >>
> >>Fill in the following:
> >>
> >>[ ]  check LICENSE, should be Apache V2
> >>
> >>[ ]  check NOTICE, should have a notice for third-party dependency if
> necessary
> >>
> >>[ ]  extract the zip and check if the source version is correct
> >>
> >>[ ]  verify the asc(PGP sign),SHA512
> >>
> >>[ ]  build the source, start nameserver and broker according to the
> quick-start
> >>
> >>[ ]  run clusterList command to see if the version is correct
> >>
> >>
> >>
> >>
> >>
> >>
> >>
> >>The vote will be open for at least 72 hours or until the necessary
> number of votes are reached.
> >>
> >>Please vote accordingly:
> >>
> >>
> >>
> >>
> >>[ ] +1 approve
> >>
> >>[ ] +0 no opinion
> >>
> >>[ ] -1 disapprove with the reason
> >>
> >>
> >>
> >>
> >>Thanks
> >>
> >>The Apache RocketMQ Team
>

Re: [VOTE]: Release Apache RocketMQ Golang SDK 5.0.0 RC1

[heng du]

+1
I checked：
(1).License and Notice are correct in the source package.
(2).All files have license headers in source package if necessary.
(3)Hash and Tag in GitHub repo is matching the current artifacts.

Xinyu Zhou  于2022年9月19日周一 16:05写道：

> +1
>
> A small problem: the artifact contains other language implementations,
> remember to remove it in the next release.
>
> On Fri, Sep 16, 2022 at 11:20 PM Zhanhui Li  wrote:
>
> > Hello RocketMQ Community,
> >
> > This is the vote for 5.0.0 of Apache RocketMQ Golang SDK.
> >
> > Golang SDK 5.x series are built on top of
> > https://github.com/apache/rocketmq-apis, following the same concept and
> > model as those of Java/C++ 5.x;
> >
> > The artifacts:
> >
> >
> https://dist.apache.org/repos/dist/dev/rocketmq/rocketmq-clients/rocketmq-client-golang/5.0.0-rc1
> >
> > Git tag for the release:
> >
> >
> https://github.com/apache/rocketmq-clients/releases/tag/rocketmq-client-golang-5.0.0-rc1
> >
> > Hash for the release tag:
> > 3914b66539ca5216f9f82332769dc76ddac27f5d
> >
> > Release Notes:
> > [1] Support publishing standard/FIFO/timed messages;
> >
> > [2] Support consuming messages through SimpleConsumer;
> >
> > [3] Support OpenTelemetry compatible metrics exporting;
> >
> > The artifacts have been signed by Key:
> > 462BE3C1C0231675374D0D93B96ECC1229F96FDD, which can be found in the key
> > file:
> > https://dist.apache.org/repos/dist/dev/rocketmq/KEYS
> >
> > The vote will be open for at least 72 hours or until the necessary number
> > of votes is collected.
> >
> > Please vote accordingly:
> >
> > [ ] +1 approve
> > [ ] +0 no opinion
> > [ ] -1 disapprove with the reason
> >
> > Thanks,
> > The Apache RocketMQ Team
> >
>

Re: [VOTE] Release Apache RocketMQ Operator 0.3.0

[heng du]

+1
I checked:
ok check LICENSE, should be Apache V2
ok check NOTICE, should have a notice for third-party dependency if
necessary
ok deploy Apache RocketMQ by Operator

Gaoyang Cai  于2022年9月13日周二 11:25写道：

> Hello RocketMQ Community,
>
>
> This is the vote for 0.3.0 release of Apache RocketMQ Operator.
>
> In this release, accessing Apache RocketMQ from outside the Kubernetes
> cluster is available, the addresses of Name Servers can be set
> automatically, memory limit in container is sensible so that calculation of
> JVM parameters is more accurate. The version of operator-sdk has been
> updated to 1.16. Also, the docker repository for rocketmq-operator has been
> moved to an official repository under Apache.
>
>
>
> Docker image for Apache RocketMQ Operator: apache/rocketmq-operator:0.3.0
>
> Docker image repo:
>
> https://hub.docker.com/layers/apache/rocketmq-operator/0.3.0/images/sha256-7fe24ce7cbac5fca29b6d0b2412e388de084b19ce1ac189734661b94037d49c7?context=explore
>
>
> Git tag and release notes for the release:
> https://github.com/apache/rocketmq-operator/releases/tag/0.3.0
>
>
> Hash for the release tag:
> 23fb2eb094470d60b964aef8539f4a4ae3a752c6
>
>
> Checklist for reference:
> Note that this is not an official policy but may help with checking
> releases.
>
> Fill in the following:
> [ ]  check LICENSE, should be Apache V2
> [ ]  check NOTICE, should have a notice for third-party dependency if
> necessary
> [ ]  verify the hash for release tag and docker image is correct
> [ ]  deploy Apache RocketMQ by Operator
>
>
>
> The vote will be open for at least 72 hours or until the necessary number
> of votes are reached.
>
> Please vote accordingly:
>
> [ ] +1 approve
>
> [ ] +0 no opinion
>
> [ ] -1 disapprove with the reason
>
>
>
>
> Thanks,
>
> The Apache RocketMQ Team

Re: [DISSCUSS] New Apache RocketMQ official website released

[heng du]

@Zhanhui Li

The new official website provides support for both Chinese and English,
https://rocketmq.apache.org/en/.

The new official website is based on retaining the original content. It not
only brings a brand new interface but also adds a lot of documents. It was
completed by the community developers.  At present, there are indeed
problems of one kind or another. The above problems you mentioned can be
improved by submitting PRs, and more developers will be involved to help
this website mature. Our goal is to make things happen. happen and move in
the right direction

Zhanhui Li  于2022年9月5日周一 11:10写道：

> Hi,
>
> I found the preview website has been brought online without a vote and
> dozens of bugs are not fixed, which causes RocketMQ inaccessible to
> non-Chinese speakers.
>
> I suggest to revert the online action, postpone the online action until the
> new website is mature enough.
>
> Zhanhui Li
>
> On Mon, Aug 22, 2022 at 10:25 AM Zhanhui Li  wrote:
>
> > After a quick preview of the proposing sites, I found a few issues:
> > 1. https://rocketmq.netlify.app/en/docs/ the comparison table should be
> > transposed.
> > 2. "Contribute Instruction" should be "Contribution Guide"
> > 3. "Contribute" points to the Team panels, the menu item is inconsistent
> > with its content;
> > 4.  Guess it is a good idea to have a breadcrumb section
> > 5. Download page, mixing 4.x and 5.x releases looks less neat. Better to
> > separate them;
> > 6. When English is selected, a lot of Chinese menus/titles are still
> > shown;
> > 7. Search is not working yet; Search field is editable;
> >
> > Zhanhui Li
> >
> > On Mon, Aug 22, 2022 at 10:13 AM 周波  wrote:
> >
> >> Thank you for your affirmation and suggestions for the work of the new
> >> website. The new website has not been completed. The link provided is
> only
> >> a demo, not the final version. It will be checked before it goes online.
> >> Please continue to pay attention
> >>
> >> Xiaorui Wang  于2022年8月21日周日 22:27写道：
> >>
> >> > Thank you all for contributing to the new website project. I am
> >> delighted
> >> > to see the new RocketMQ website.
> >> >
> >> >
> >> > I thoroughly read every page on the new site, which features a dynamic
> >> > design, rich content and easy navigation to visitors. BTW, I didn't
> see
> >> the
> >> > Origin page [1] which was on the official website before. I'm not sure
> >> if
> >> > you accidentally missed it. While the original page is helpful for
> >> learning
> >> > more about RocketMQ, I still advise combining it with team menu.
> >> >
> >> > [1] https://rocketmq.apache.org/about/origin/
> >> >
> >> > Best regards,
> >> >
> >> > Xiaorui Wang[#] - Apache RocketMQ PMC chair
> >> > [#] https://github.com/vintagewang
> >> >
> >> >
> >> > On Sun, Aug 21, 2022 at 6:32 PM 周波  wrote:
> >> >
> >> > > Hi, RocketMQ Community:
> >> > >
> >> > > The Apache RocketMQ official website has been with us for many years
> >> and
> >> > > has become an important channel for many developers to know,
> >> understand
> >> > and
> >> > > learn RocketMQ. We are well aware of the importance of the official
> >> > website
> >> > > to RocketMQ. With the continuous evolution and iteration of the
> >> RocketMQ
> >> > > version, we will soon usher in the release of the major version 5.0.
> >> The
> >> > > Apache RocketMQ official website has also ushered in a major
> upgrade,
> >> > with
> >> > > a new homepage, new multi-language and multi-version support, and
> the
> >> new
> >> > > official website will be released soon, stay tuned.
> >> > >
> >> > > Early access to the latest official website.
> >> > > https://rocketmq.netlify.app/
> >> > >
> >> > > Thanks
> >> > > zhou bo
> >> > >
> >> >
> >>
> >
>

Re: [Discuss] RocketMQ-MQTT 1.0.0 LTS release

[heng du]

+1 for voting

yukon  于2022年8月27日周六 10:40写道：

> +1 for releasing this version.
>
> Since this is the first version, please notice that all the source files
> should have an apache license header, it's recommended to add a GitHub
> action to check it, you can refer to here:
>
> https://github.com/apache/rocketmq-clients/blob/master/.github/workflows/license_checker.yaml
>
> And, please note the license compatibility of binary dependencies, For more
> details please refer to: https://www.apache.org/legal/resolved.html
>
> Regards,
> yukon
>
> On Sat, Aug 27, 2022 at 9:51 AM Ping Wang  wrote:
>
> > Hello, RocketMQ Community,
> >
> >
> > This is the discussion for the release of RocketMQ-MQTT 1.0.0
> LTS（long-term
> > support ） version. This is the first version. The subsequent bug fixes
> will
> > be back ported to this version from the trunk in a timely manner,  and
> the
> > LTS version has a support period of 18 months.
> >
> >
> > If there are no other sounds, I would like to call for a vote for
> > RocketMQ-MQTT 1.0.0 release :-)
> >
>

[ANNOUNCE] New PMC member for Apache RocketMQ: Qingshan Lin

[heng du]

Hi Apache RocketMQ Community,

The Project Management Committee (PMC) for Apache RocketMQ has invited Qingshan
Lin[1][2] (apache id: linhill)  to become PMC Member and we are pleased to
announce that he has accepted.

In RocketMQ 5.0, Qingshan innovatively proposed a new POP consumption model
in RIP-19, which enhanced RocketMQ's core competitiveness in the Messaging
field in a more cloud-native way, and laid the foundation for the
subsequent emergence of gRPC proxy .

Qingshan also actively participates in the community and actively promotes
the Apache way. As a release manager, he leads the release of the
5.0.0-alpha version of the community. In addition, with his great work,
 three developers including @Yangkun Ai @Lin Shen @chenzlalvin quickly
familiar with the apache way and became committers.

In addition, in the first Apache RocketMQ Summit, Qingshan, as one of the
organizers, attracted nearly 40 speakers from more than 20 companies to
share, and the entire Summit was viewed by more than 190,000 people, with
over 1 million total views. Greatly enhanced the influence of RocketMQ and
attracted more developers into the community. Additionally, He also did
several public presentations to advocate Apache RocketMQ and Apache way.


Congrats, guy :-)

Notice: Being a PMC member enables assistance with the management and
guides the direction of the project.


[1] https://github.com/apache/rocketmq/commits?author=hill007299
[2] https://lists.apache.org/list?dev@rocketmq.apache.org:lte=24M:hill007299
Best Regards,
Apache RocketMQ Team

Re: [ANNOUNCE]New Committers of Apache RocketMQ: Sun Xiaojian(apache id: sunxiaojian)

[heng du]

Congrats！@sunjiaojian929

周波  于2022年8月2日周二 17:40写道：

>- congrats
>
>
> ShannonDing  于2022年8月1日周一 15:18写道：
>
> > Hi Apache RocketMQ Community,
> >
> >
> >
> >
> > The Project Management Committee (PMC) for Apache RocketMQ has invited
> >
> > Sun Xiaojian(apache id: sunxiaojian),
> >
> > to become a committer, and we are pleased to announce that he has
> > accepted.
> >
> >
> >
> >
> > Congrats, guy :-)
> >
> >
> >
> >
> > Best Wishes,
> >
> > ShannonDing
>

Re: ​[VOTE]Release Apache RocketMQ Client Go Native 2.1.1.

[heng du]

+1
I checked：

Source code artifacts have correct names matching the current release.
License and Notice are correct in the source package.
All files have license headers in source package if necessary.
Hash and Tag in GitHub repo is matching the current artifacts.




ShannonDing  于2022年7月25日周一 21:16写道：

> Hello RocketMQ Community,
>
>
>
> This is the vote for version 2.1.1 of Apache RocketMQ Client Go Native.
>
> The main goal of this release is to improve stability, usability, and fix
> bugs and  implement some new features mainly including request-reply mode,
> consuming messages from slave node and supporting IPv6 and so on.
>
>
>
> The artifacts:
>
>
> https://dist.apache.org/repos/dist/dev/rocketmq/rocketmq-client-go/2.1.1-rc3/
>
> Git tag for the release:
>
> https://github.com/apache/rocketmq-client-go/releases/tag/v2.1.1
>
> Hash for the release tag:
>
> 129701aef56b3bf215b230ed9285ccb17dc18fe9
>
> Release Notes:
>
>
> http://rocketmq.apache.org/release_notes/release-notes-rocketmq-client-go-2.1.1/
>
> The artifacts have been signed with Key :
>
> BC9E172DE1BA5B24EBB4A628177B55985D75751B, which can be found in the keys
>
> file:
>
> https://dist.apache.org/repos/dist/dev/rocketmq/KEYS
>
>
>
>
> Checklist for reference,
>
> Note that this is not official policy but may help with checking releases.
>
> Fill in the following:
>
> [ ]  Checksums and PGP signatures are valid for Source package.
>
> [ ]  Source code artifacts have correct names matching the current release.
>
> [ ]  License and Notice are correct in source package.
>
> [ ]  All files have license headers in source package if necessary.
>
> [ ]  No compiled archives bundled in source archive.
>
> [ ]  Hash and Tag in GitHub repo is matching the current artifacts.
>
> As we don’t release binary package for Apache RocketMQ Go SDK, the binary
> package checklist should not be followed.
>
> And any other check point is welcomed and please feel free to reply to
> this email, we sincerely hope to your feedback.
>
>
>
>
> The vote will be open for at least 72 hours or until necessary number of
>
> votes are reached.
>
> Please vote accordingly:
>
>
>
>
> [ ] +1 approve
>
> [ ] +0 no opinion
>
> [ ] -1 disapprove with the reason
>
>
>
>
> Thanks,
>
> The Apache RocketMQ Team

Re: [VOTE]Release Apache RocketMQ APIs 2.0.0 RC1

[heng du]

+1

I checked

1.Checksums and PGP signatures are valid for source package.
2. The Apache V2 license file is included in the package;

Zhanhui Li  于2022年7月18日周一 11:21写道：

> +1 binding
>
> I checked
>
> 1. Checksum and PGP signature;
> 2. License headers are included in Protobuf files;
> 3. The Apache V2 license file is included in the package;
>
>
> On Mon, Jul 18, 2022 at 11:07 AM lollipop  wrote:
>
> > +1，checked：
> >
> > [OK ]  Checksums and PGP signatures are valid for source package.
> > [OK ]  License and Notice are correct in source package.
> >
> > On Fri, Jul 15, 2022 at 11:13 PM aaron ai  wrote:
> >
> > > Hello RocketMQ Community,
> > >
> > > This is the vote for 2.0.0 RC1 of Apache RocketMQ APIs.
> > >
> > > RocketMQ APIs use Protocol Buffers version 3 (proto3) as their
> Interface
> > > Definition Language (IDL) to define the API interface and the structure
> > of
> > > the payload messages.
> > >
> > > The artifacts:
> > >
> > > https://dist.apache.org/repos/dist/dev/rocketmq/2.0.0-rc1
> > >
> > > The staging repo:
> > >
> > >
> >
> https://repository.apache.org/content/repositories/orgapacherocketmq-1091/
> > >
> > > Git tag for the release:
> > >
> > > https://github.com/apache/rocketmq-apis/releases/tag/v2.0
> > >
> > >
> >
> https://github.com/apache/rocketmq-apis/releases/tag/rocketmq-proto-2.0.0
> > >
> > > Hash for the release tag:
> > >
> > > 303962118171075c3a5a8c395822fecfdf492d6f
> > >
> > > Relate Notes:
> > >
> > > https://github.com/apache/rocketmq-apis/releases/tag/v2.0
> > >
> > >
> >
> https://github.com/apache/rocketmq-apis/releases/tag/rocketmq-proto-2.0.0
> > >
> > > The artifacts have been signed with Key :
> > >
> > > 3A11FEBBD64C807A233BF1F27C46C79BD4D29011, which can be found in the
> keys
> > > file: https://dist.apache.org/repos/dist/dev/rocketmq/KEYS
> > >
> > > Fill in the following:
> > >
> > > [+]  check LICENSE, should be Apache V2
> > >
> > > [+]  check NOTICE, should have a notice for third-party dependency if
> > > necessary
> > >
> > > [+]  extract the zip and check if the source version is correct
> > >
> > > [+]  verify the asc(PGP sign),SHA512
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > > The vote will be open for at least 72 hours or until the necessary
> number
> > > of votes are reached.
> > >
> > > Please vote accordingly:
> > >
> > >
> > >
> > >
> > > [ ] +1 approve
> > >
> > > [ ] +0 no opinion
> > >
> > > [ ] -1 disapprove with the reason
> > >
> > >
> > >
> > >
> > > Thanks
> > >
> > > The Apache RocketMQ Team
> > >
> >
>

Re: [VOTE][RIP-45]RocketMQ Replicator 2.0

[heng du]

+1

dongeforever  于2022年7月12日周二 14:44写道：

> +1.
>
> BTW, currently, it does not have an offset replicator for Group Offsets.
>
> zhibo li  于2022年7月12日周二 14:32写道：
>
> > Hi, RocketMQ Community,
> >
> >
> > As discussed in the previous email, we launched a new RIP 45 to enhance
> > RocketMQ Replicator. Now the shepherds @duhenglucky and @dongeforever are
> > willing to support the RIP, so I think it is time to start an email
> thread
> > to enter the voting process.
> >
> >
> > The vote will be open for at least 72 hours or until a necessary number
> of
> > votes are reached.
> >
> >
> > Please vote accordingly:
> >
> >
> > [ ] +1 approve
> >
> > [ ] +0 no opinion
> >
> > [ ] -1 disapprove with the reason
> >
> >
> >
> >
> >
> > Best Regards!
> >
> > Lizhibo
> >
> >
> >
> > links:
> >
> > English proposal:
> >
> >
> https://docs.google.com/document/d/1_gd3ijNW38cHQTeI_iOUX9hg4n_RVGQDLnZxLMJr0lg/edit?usp=sharing
> > <
> >
> https://docs.google.com/document/d/1tSJkor_3Js4NBaVA0UENGyM8Mh0SrRMXszRyI91hjJ8/edit?usp=sharing
> > >
> >
> > Chinese proposal:
> > https://shimo.im/file-invite/3EMTZwcWNFh8NW4Vgj4dKtlmGJXK6/
> >
>

Re: [VOTE] The code of 5.0.0-beta merge into develop branch

[heng du]

+1
Multiple active branches have brought a heavy burden to the maintenance of
RocketMQ, and it has been half a year since the release of 5.0 alpha, and
the continued maintenance of the LTS version also avoids stability problems

lixiaoshuang  于2022年7月12日周二 10:30写道：

> +1 approve
>
>
>
>
> --原始邮件--
> 发件人:
>   "dev"
> <
> jinrongt...@apache.org;
> 发送时间:2022年7月12日(星期二) 上午10:18
> 收件人:"dev@rocketmq.apache.org"
> 主题:[VOTE] The code of 5.0.0-beta merge into develop branch
>
>
>
> Hi, RocketMQ Community,
>
> As discussed in the previous email, we want to merge the code of the
> 5.0-beta into develop branch. We also create a new branch 4.9.x to fix bugs
> in the 4.9.4 LTS version.
> So I start this email thread to enter the voting process for the previous
> discussion.
>
>
> Note: after the 5.0.0-beta code is merged into develop branch, some large
> pull requests that have not been merged may have code conflicts, which need
> to be resolved by yourself.
>
>
> The vote will be open for at least 72 hours or until a necessary number of
> votes are reached.
>
>
> Please vote accordingly:
> [ ] +1 approve
> [ ] +0 no opinion
> [ ] -1 disapprove with the reason
>
>
> Best Regards!
> Rongtong Jin

Re: [VOTE][RIP-44]Support DLedger Controller

[heng du]

+1
This RIP not only provides a more flexible HA model, but also unifies
RocketMQ's storage and replication capabilities

dongeforever  于2022年6月30日周四 15:16写道：

> +1
> Great Job.
> This RIP will make a big difference to the HA Model of RocketMQ.
>
> jinrongtong  于2022年6月27日周一 11:32写道：
>
> > Hi, RocketMQ Community,
> >
> > As discussed in the previous email, we launched a new RIP 44 to support
> > dledger controller. Now the shepherds @duhenglucky and @dongeforever are
> > willing to support the RIP, so I think it is time to start an email
> thread
> > to enter the voting process.
> >
> > The vote will be open for at least 72 hours or until a necessary number
> of
> > votes are reached.
> >
> > Please vote accordingly:
> >
> > [ ] +1 approve
> > [ ] +0 no opinion
> > [ ] -1 disapprove with the reason
> >
> >
> >
> >
> > Best Regards!
> > Rongtong Jin
> >
> >
> > links:
> > Discuss email:
> > https://lists.apache.org/thread/bvykv62y4ytqrox5892mgyr1qvc7cngb
> > English proposal:
> >
> https://docs.google.com/document/d/1tSJkor_3Js4NBaVA0UENGyM8Mh0SrRMXszRyI91hjJ8/edit?usp=sharing
> > Chinese proposal: https://shimo.im/docs/N2A1Mz9QZltQZoAD/
> > Proposal sharing video:
> >
> https://meeting.tencent.com/v2/cloud-record/share?id=36398686-8f05-488b-acf7-91fef5498689=3
>

Re: [VOTE][RIP-43] Support Timing Messages with Arbitrary Time Delay

[heng du]

+1

dongeforever  于2022年6月30日周四 15:13写道：

> +1
>
> 643422162 <643422...@qq.com.invalid> 于2022年6月24日周五 22:13写道：
>
> > +1
> >
> >
> > -- 原始邮件 --
> > 发件人: "季俊涛"<3160102...@zju.edu.cn;
> > 发件时间: 2022-06-23 17:48
> > 收件人: "dev";
> > 主题: [VOTE][RIP-43] Support Timing Messages with Arbitrary Time Delay
> >
> >
> >
> > Hi, RocketMQ Community,  As discussed in the previous email, we launched
> a
> > new RIP to support Timing Messages with Arbitrary Time Delay. Now the
> > shepherd @dongeforever is willing to support the RIP, so I think it is
> time
> > to start an email thread to enter the voting process. The vote will be
> open
> > for at least 72 hours or until a necessary number of votes are reached.
> > Please vote accordingly: [ ] +1 approve [ ] +0 no opinion [ ] -1
> disapprove
> > with the reason Best Regards! Juntao Ji links:  Google Doc:
> >
> https://docs.google.com/document/d/1D6XWwY39p531c2aVi5HQll9iwzTUNT1haUFHqMoRkT0/edit?usp=sharing
> > Shimo:https://shimo.im/docs/gXqme9PKKpIeD7qo/
>

Re: [VOTE]Release Apache RocketMQ 4.9.4 RC1

[heng du]

+1
I checked：



[OK ]  Checksums and PGP signatures are valid for source package.
[OK ]  Source code artifacts have correct names matching the current
release.
[OK ]  License and Notice are correct in source package.
[OK ]  All files have license headers in source package if necessary.
[OK ]  No compiled archives bundled in source archive.
[OK ]  Hash and Tag in GitHub repo are matching the current artifacts.
[OK ] Source code artifacts have correct names matching the current release.
[OK ] Build the source, start nameserver, and broker according to the
quick-start.



jinrongtong  于2022年6月21日周二 14:41写道：

> +1, I checked[OK] Checksums and PGP signatures are valid for
> Binary package.[OK] Source code artifacts have correct names
> matching the current release.[OK] Binary artifacts have correct
> names matching the current release.[OK] Hash and Tag in GitHub
> repo is matching the current artifacts.[OK] The code can be
> built success in the source package.[OK] Start nameserver and
> broker according to the quick-start[OK] Run clusterList command
> to see if the version is correct
> At 2022-06-21 10:25:34, "hill"  wrote:
> >Hello RocketMQ Community,
> >
> >
> >
> >
> >This is the vote for 4.9.4 RC1 of Apache RocketMQ.
> >
> >This release is to improve some features and issues for apache
> rocketmq,such as enhance acl , package dependency optimization,  improve
> encode/decode performance，fix some bugs and issues and so on.
> >
> >
> >
> >
> >The artifacts:
> >
> >https://dist.apache.org/repos/dist/dev/rocketmq/4.9.4-rc1/
> >
> >
> >
> >
> >The staging repo:
> >
> >
> https://repository.apache.org/content/repositories/orgapacherocketmq-1086/
> >
> >
> >
> >
> >Git tag for the release:
> >
> >https://github.com/apache/rocketmq/releases/tag/rocketmq-all-4.9.4
> >
> >
> >
> >
> >Hash for the release tag:
> >
> >06f2208a34907211591114f6b0d327168c250fb3
> >
> >
> >
> >
> >Release Notes:
> >
> >https://rocketmq.apache.org/release_notes/release-notes-4.9.4
> >
> >
> >
> >
> >The artifacts have been signed with Key :
> >
> >D011F2A8C9474A34099477A5C99B3EAC6B119386, which can be found in the keys
> file: https://dist.apache.org/repos/dist/dev/rocketmq/KEYS
> >
> >
> >
> >
> >Checklist for reference,
> >
> >Note that this is not an official policy but may help with checking
> releases.
> >
> >
> >
> >
> >Fill in the following:
> >
> >[ ]  check LICENSE, should be Apache V2
> >
> >[ ]  check NOTICE, should have a notice for third-party dependency if
> necessary
> >
> >[ ]  extract the zip and check if the source version is correct
> >
> >[ ]  verify the asc(PGP sign),SHA512
> >
> >[ ]  build the source, start nameserver and broker according to the
> quick-start
> >
> >[ ]  run clusterList command to see if the version is correct
> >
> >
> >
> >
> >
> >
> >
> >The vote will be open for at least 72 hours or until the necessary number
> of votes are reached.
> >
> >Please vote accordingly:
> >
> >
> >
> >
> >[ ] +1 approve
> >
> >[ ] +0 no opinion
> >
> >[ ] -1 disapprove with the reason
> >
> >
> >
> >
> >Thanks
> >
> >The Apache RocketMQ Team
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
>

Re: [ANNOUNCE]New Committer of Apache RocketMQ: Ni Ze(apache id:karp)

[heng du]

Congrats！

ShannonDing  于2022年6月17日周五 14:38写道：

>
>
>
> Hi Apache RocketMQ Community,
>
>
>
>
> The Project Management Committee (PMC) for Apache RocketMQ has invited
>
> Ni Ze(apache id:karp),
>
> to become a committer, and we are pleased to announce that he has
> accepted.
>
>
>
>
> Congrats, guy :-)
>
>
>
>
> Best Wishes,
>
> ShannonDing

Re: [ANNOUNCE]New Committers of Apache RocketMQ: Lin Shen(shenlin) and Yangkun Ai(aaronai)

[heng du]

Congrats

yukon  于2022年6月15日周三 10:10写道：

> Hi Apache RocketMQ Community,
>
> The Project Management Committee (PMC) for Apache RocketMQ has invited Lin
> Shen (apache id: shenlin, github id: 2011shenlin) and Yangkun Ai (apache
> id: aaronai, github id: aaron-ai) to become committers, and we are pleased
> to announce that they have accepted.
>
> Congrats, guys :-)
>
> Best regards,
> Yukon
>

Re: [DISCUSS][RIP-42] Support rocketmq schema registry

[heng du]

I am very happy to see this proposal. Schema not only provides rocketmq
with the ability to manage metadata, but is also an important part of
entering the data integration ecosystem.

fan wang  于2022年5月13日周五 16:20写道：

> Hi, RocketMQ Community:
>
> Currently, RocketMQ Message has no Schema constraint, and the serialization
> and deserialization processes are entirely left to users. This leads to
> some problems with end-to-end type safety and coupling of upstream and
> downstream. So, we plan to build a schema management center to enhance type
> safety and application extensibility for structured data.
>
> I have drafted the proposal: RIP-42 Support rocketmq schema registry,
> refer: https://shimo.im/docs/Ee32MWDG1WFmKRA2 for more details.
>
> Please reply to this email If you have any questions or suggestions.
>
> Thanks
>
> wangfan
>

Re: [VOTE][RIP-41]Build rocketmq e2e test and github action cicd

[heng du]

+1

YuanchenZhang  于2022年5月5日周四 10:46写道：

> Hi, RocketMQ Community,
>
>
>
> As discussed in the previous email, we launched a new RIP to support
> rocketmq e2e test and github action cicd. Now the shepherds @duhenglucky
> are willing to support the RIP, so I think it is time to start an email
> thread to enter the voting process.
>
> The vote will be open for at least 72 hours or until a necessary number of
> votes are reached.
>
>
>
>
> Please vote accordingly:
>
>
>
>
> [ ] +1 approve
>
> [ ] +0 no opinion
>
> [ ] -1 disapprove with the reason
>
>
>
>
> Best Regards!
>
> YuanchenZhang
>
>
>
>
> links:
>
>
> https://docs.google.com/document/d/1NqVx7oXvJRnJA_qaZk-MH193i5at9KXPb7q2TRji8go/edit?usp=sharing
>
> https://shimo.im/docs/pmkxQEOZmDiLwdAN/
>
>
>

[RESULT][VOTE][RIP-40] Quickly deploy of Apache Rocketmq Cluster

[heng du]

Hello RocketMQ Community,

This is the vote result for the kickoff of RIP-40 Quickly deploy of Apache
Rocketmq Cluster
and it has
been passed with [3] binding +1s, [2] non-binding:

*Binding votes +1s:*

Heng Du (duhengfore...@apache.org )
ShannonDing(shannond...@apache.org )
Rongtong Jin(jinrongton...@mails.ucas.ac.cn)

*Non-binding votes +1s:*

caigy (csgyt...@163.com)
zhiboli(osgooli...@gmail.com)



This RIP will be accepted and its status will be updated to RocketMQ wiki
soon.


Thanks.

孙先生  于2022年4月18日周一 17:11写道：

>
>
>
> Thank you,
> I've actually finished the development.
>
>
>
> https://github.com/apache/rocketmq-externals/pull/879
>
>
>
>
>
>
>
>
>
>
>
> At 2022-04-18 10:31:45, "yukon"  wrote:
> >Hi,
> >
> >There are some playbooks to deploy rocketmq that could be your reference:
> >https://github.com/openmessaging/benchmark/tree/master/driver-rocketmq
> >
> >
> >
> >On Mon, Apr 18, 2022 at 9:59 AM ShannonDing  wrote:
> >
> >> +1,
> >>
> >> At 2022-04-15 10:23:25, "孙先生"  wrote:
> >> >Hi, RocketMQ Community,
> >> >
> >> >
> >> >
> >> >
> >> >As discussed in the previous email, we launched a new RIP to Quickly
> >> deploy Apache Rocketmq Cluster. Now the shepherds @duhengforever are
> >> willing to support the RIP, so I think it is time to start an email
> thread
> >> to enter the voting process.
> >> >
> >> >
> >> >
> >> >
> >> >
> >> >
> >> >
> >> >The vote will be open for at least 72 hours or until a necessary number
> >> of votes are reached.
> >> >
> >> >
> >> >
> >> >
> >> >Please vote accordingly:
> >> >
> >> >
> >> >
> >> >
> >> >[ ] +1 approve
> >> >
> >> >[ ] +0 no opinion
> >> >
> >> >[ ] -1 disapprove with the reason
> >>
>

Re: [VOTE] Release Apache RocketMQ Streams 1.0.1-preview RC1

[heng du]

+1
I checked：

[ ok]  Checksums and PGP signatures are valid for source package.

[ ok]  Source code artifacts have correct names matching the current release
.

[ ok]  License and Notice are correct in source package.

[ ok] All files have license headers in source package if necessary.

[ ok]  No compiled archives bundled in source archive.

[ ok] Hash and Tag in GitHub repo are matching the current artifacts.

[ ok]  The code can be built success in the source package.



zhibo li  于2022年4月15日周五 16:55写道：

> +1
>
> zhibo li  于2022年4月13日周三 10:13写道：
>
>> Hello RocketMQ Community,
>>
>>
>>
>> This is the vote for the 1.0.1-preview release of Apache RocketMQ-Streams.
>>
>>
>> The artifacts:
>>
>>
>> https://dist.apache.org/repos/dist/dev/rocketmq/rocketmq-streams/1.0.1-preview-rc1/
>> 
>>
>>
>> The staging repo:
>>
>> https://repository.apache.org/content/repositories/orgapacherocketmq-1085
>>
>>
>> Git tag for the release:
>>
>>
>> https://github.com/apache/rocketmq-streams/releases/tag/rocketmq-streams-1.0.1-preview
>>
>>
>> Hash for the release tag:
>>
>> 5e3ffb2ddda8234928006086f711b051a29657f6
>>
>>
>> Release Notes:
>>
>>
>> http://rocketmq.apache.org/release_notes/release-notes-rocketmq-streams-1.0.0-preview/
>>
>>
>> The artifacts have been signed with Key :
>>
>> 5F4943FC0449417C342D70B4AA685CA96FF11BAF, which can be found in the keys
>> file:
>>
>>
>> https://dist.apache.org/repos/dist/dev/rocketmq/KEYS
>>
>>
>> Checklist for reference,
>>
>> Note that this is not an official policy but may help with checking
>> releases.
>>
>>
>> Fill in the following:
>>
>> [ ]  Checksums and PGP signatures are valid for source package.
>>
>> [ ]  Source code artifacts have correct names matching the current
>> release.
>>
>> [ ]  License and Notice are correct in source package.
>>
>> [ ]  All files have license headers in source package if necessary.
>>
>> [ ]  No compiled archives bundled in source archive.
>>
>> [ ]  Hash and Tag in GitHub repo are matching the current artifacts.
>>
>> [ ]  The code can be built success in the source package.
>>
>>
>> And any other checkpoint is welcomed and please feel free to reply to
>> this email, we sincerely hope for your feedback.
>>
>> The vote will be open for at least 72 hours or until a necessary number
>> of votes are reached.
>>
>>
>> Please vote accordingly:
>>
>> [ ] +1 approve
>>
>> [ ] +0 no opinion
>>
>> [ ] -1 disapprove with the reason
>>
>>
>>
>> Thanks,
>>
>> The Apache RocketMQ Team
>>
>

Re: [VOTE][RIP-40] Quickly deploy of Apache Rocketmq Cluster

[heng du]

+1

孙先生  于2022年4月15日周五 10:23写道：

> Hi, RocketMQ Community,
>
>
>
>
> As discussed in the previous email, we launched a new RIP to Quickly
> deploy Apache Rocketmq Cluster. Now the shepherds @duhengforever are
> willing to support the RIP, so I think it is time to start an email thread
> to enter the voting process.
>
>
>
>
>
>
>
> The vote will be open for at least 72 hours or until a necessary number of
> votes are reached.
>
>
>
>
> Please vote accordingly:
>
>
>
>
> [ ] +1 approve
>
> [ ] +0 no opinion
>
> [ ] -1 disapprove with the reason

Re: [VOTE]Release Apache RocketMQ Spring 2.2.2 RC1

[heng du]

+1
Checked:
[ok]  Checksums and PGP signatures are valid for source package.
[ok]  Source code artifacts have correct names matching the current release.
[ok]  License and Notice are correct in source package.
[ok] All files have license headers in source package if necessary.
[ok]No compiled archives bundled in source archive.
[ok] Hash and Tag in GitHub repo are matching the current artifacts.
[ok]The code can be built success in the source package.

nize  于2022年4月11日周一 15:59写道：

> +1
>
> I checked:
>
> Checksums and PGP signatures are valid for source package.
> Source code artifacts have correct names matching the current release.
> License and Notice are correct in source package.
> All files have license headers in source package if necessary.
> The code can be built success in the source package.
>
> jinrongtong  于2022年4月6日周三 21:13写道：
>
> > Hello RocketMQ Community,
> >
> > This is the vote for the 2.2.2 release of Apache RocketMQ-Spring.
> >
> >
> > The artifacts:
> >
> https://dist.apache.org/repos/dist/dev/rocketmq/rocketmq-spring/2.2.2-rc1/
> >
> >
> > The staging repo:
> >
> https://repository.apache.org/content/repositories/orgapacherocketmq-1084
> >
> >
> > Git tag for the release:
> >
> >
> https://github.com/apache/rocketmq-spring/releases/tag/rocketmq-spring-all-2.2.2
> >
> >
> > Hash for the release tag:
> > 1d586a1a5280089a660c439e577fda9e9d908c76
> >
> >
> > Release Notes:
> >
> >
> http://rocketmq.apache.org/release_notes/release-notes-rocketmq-spring-2.2.2/
> >
> >
> > The artifacts have been signed with Key :
> > EC9F268B4C20590138B11FE701420E4292296EAE, which can be found in the keys
> > file:
> > https://dist.apache.org/repos/dist/dev/rocketmq/KEYS
> >
> >
> > Checklist for reference,
> > Note that this is not an official policy but may help with checking
> > releases.
> > Fill in the following:
> > [ ]  Checksums and PGP signatures are valid for source package.
> > [ ]  Source code artifacts have correct names matching the current
> release.
> > [ ]  License and Notice are correct in source package.
> > [ ]  All files have license headers in source package if necessary.
> > [ ]  No compiled archives bundled in source archive.
> > [ ]  Hash and Tag in GitHub repo are matching the current artifacts.
> > [ ]  The code can be built success in the source package.
> >
> >
> > And any other checkpoint is welcomed and please feel free to reply to
> this
> > email, we sincerely hope for your feedback.
> > The vote will be open for at least 72 hours or until a necessary number
> of
> > votes are reached.
> >
> >
> > Please vote accordingly:
> > [ ] +1 approve
> > [ ] +0 no opinion
> > [ ] -1 disapprove with the reason
> >
> >
> >
> >
> > Thanks,
> > The Apache RocketMQ Team
>

Re: [RIP]rapidly deploy of rocketmq cluster(ansible playbook)

[heng du]

可以按照这个格式，https://lists.apache.org/list?dev@rocketmq.apache.org:lte=3M:RIP-29
，使用RIP-40这个编号

孙先生  于2022年4月6日周三 17:57写道：

> 借助运维管理平台ansible的能力，通过ansible playbook提供rocketmq生态圈整合和快速部署的能力。
> ansible
> playbook将部署环境初始化、源码包下载、操作系统参数调优、broker最佳实践配置参数、rocketmq集群部署、rocketmq
> exporter部署、rocketmq exporter接入、开机自启动等功能编排到一起，形成rocketmq生态圈的自动化部署能力。
> 其中ansible
> playbook嵌入在发布流程中（下图）或者编排到terraform流程中，这在自动化运维或者vdc一键部署（SDE）有非常重要的意义。
> pr地址：https://github.com/apache/rocketmq-externals/pull/879
> translated by google:
> The RocketMQ ecosystem integration and rapid deployment capabilities are
> provided through Ansible Playbook, leveraging the capabilities of the o
> management platform Ansible.
>
> Ansible Playbook initializes the deployment environment, downloads source
> packages, tuning operating system parameters, broker best practices
> configuration parameters, RocketMQ cluster deployment, RocketMQ Exporter
> deployment, and RocketMQ The functions of my exporter access and boot up
> are arranged together to form an automated deployment capability for the
> RocketMQ ecosystem.
>
> The Ansible Playbook is embedded in the release process (below) or
> programmed into the Terraform process, which is important for automated
> operations or VDC one-click deployment (SDE).
>
>
>

Re: [VOTE][RIP-38] RocketMQ EventBridge

[heng du]

+1
rocketmq-eb relies on the data synchronization capability of
rocketmq-connect, and at the same time abstracts and implements event
access at a higher level

BTW， It is suggested that when voting, we'd better re-edit the subject
while replying to the original discussion email and change it to
[VOTE]x.

Thanks,
Heng Du

dongeforever  于2022年3月14日周一 11:28写道：

> The  RIP is great！
>
> But I still have a doubt that what's the relationship between
> rocketmq-connect and rocketmq-eventbridge.
>
> Will the two projects go forward independently or be mixed together?
>
> The doubt does not prevent the development of rocketmq-eventbrige.
>
> But it is great if someone can add more explanation to it.
>
>
> Xiaorui Wang  于2022年3月14日周一 10:57写道：
>
> > +1
> >
> > Best regards,
> >
> > Xiaorui Wang[1] - Apache RocketMQ PMC chair
> > [1] https://github.com/vintagewang
> >
> >
> > On Mon, Mar 14, 2022 at 10:40 AM aaron ai  wrote:
> >
> > > +1
> > >
> > > On Mon, Mar 14, 2022 at 10:26 AM 沈林 <2011shen...@gmail.com> wrote:
> > >
> > > > Hi, RocketMQ Community,
> > > >
> > > > This is the vote for RocketMQ EventBridge, and you can read the
> > proposal
> > > by
> > > > the link below:
> > > >
> > > >
> > >
> >
> https://docs.google.com/document/d/1RWPeORHY_-ukq8qs1a1lH80fH8vSQ44U1R9xbxgEX_c/edit?usp=sharing
> > > >
> > > > The vote will be open for at least 72 hours or until the necessary
> > number
> > > > of votes are reached.
> > > >
> > > > Please vote accordingly:
> > > > [ ] +1 approve
> > > > [ ] +0 no opinion
> > > > [ ] -1 disapprove with the reason
> > > >
> > > > Thanks,
> > > > And Best Regards!
> > > > Lin Shen 沈林
> > > >
> > > >
> > > > Xiaorui Wang  于2022年3月8日周二 12:54写道：
> > > >
> > > > > That’s terrific! It is a milestone that greatly expands the scope
> of
> > > > > RocketMQ, especially on the Cloud Platform. It requires more
> > > easy-to-use
> > > > > capabilities of event integration. Give the thumb-up for
> contributors
> > > of
> > > > > EventBridge.
> > > > >
> > > > > BTW, I would like to call on everyone here to pay more attention to
> > the
> > > > > application of RocketMQ in Cloud Native. It is a once-in-a-lifetime
> > > > > opportunity for architecture upgrade.
> > > > >
> > > > > Cloud IaaS has uncomparable advantages over IDC IaaS. Although the
> > > > > infrastructure software was designed by IDC 10 years ago, I believe
> > > that
> > > > > more and more infrastructure software will be designed for Cloud
> > > Platform
> > > > > in the future.
> > > > >
> > > > > Looking forward to this technology upgrade of RocketMQ can keep
> pace
> > > with
> > > > > the times.
> > > > >
> > > > > Cheers
> > > > >
> > > > > Xiaorui Wang 王小瑞
> > > > > Apache RocketMQ PMC Chair
> > > > >
> > > > > On Tue, Mar 8, 2022 at 10:46 AM 沈林 <2011shen...@gmail.com> wrote:
> > > > >
> > > > > > Hi, RocketMQ Community:
> > > > > >
> > > > > > We are building a new system “rocketmq-eventbridge” based on
> > > rocketmq,
> > > > > > it’s an implementation of an event bus that makes it easier to
> > build
> > > > > > event-driven applications.
> > > > > >
> > > > > > We have written the proposal and you can see it by the link
> below:
> > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >
> https://docs.google.com/document/d/1RWPeORHY_-ukq8qs1a1lH80fH8vSQ44U1R9xbxgEX_c/edit?usp=sharing
> > > > > > <
> > > > > >
> > > > >
> > > >
> > >
> >
> https://docs.google.com/document/d/1RWPeORHY_-ukq8qs1a1lH80fH8vSQ44U1R9xbxgEX_c/edit?usp=sharing
> > > > > > >
> > > > > >
> > > > > >
> > > > > > Please reply to this email if you have any suggestions.
> > > > >
> > > >
> > >
> >
>

Re: [ANNOUNCE]New Committers of Apache RocketMQ: Zhi Pan(panzhi33) and Hongjian Fei(hongjianfei)

[heng du]

Congrats, guys :-)


jinrongtong  于2022年3月17日周四 17:03写道：

> Hi Apache RocketMQ Community,
>
> The Project Management Committee (PMC) for Apache RocketMQ has invited
> Zhi Pan (apache id: panzhi33, github id:panzhi33) and Hongjian Fei (apache
> id: hongjianfei, github id:Erik1288)
> to become committers, and we are pleased to announce that they have
> accepted.
>
> Congrats, guys :-)
>
> Best Wishes,
> RongtongJin
>
>
>
>

Re: [DISCUSS] RIP-35 queue service framework(QSF)

[heng du]

Nice to see this proposal of yours, but it seems a bit like what
rocketmq-spring[1] does, so can you elaborate on the difference between QSF
and rocketmq-spring?

[1]https://github.com/apache/rocketmq-spring

yukon  于2022年3月16日周三 20:23写道：

> Could you please provide some demos to show how we use
> QSFProducer/Consumer?
>
> On Wed, Mar 16, 2022 at 6:49 PM Jason.Chen  wrote:
>
> > I am sorry that the RIP mail format is incorrect, and i write a
> > well-formed google doc version here:
> >
> >
> >
> https://docs.google.com/document/d/10wSe24TAls7J9y0Ql4MYo73FX8g1aX9guoxBxzQhJgg
> >
> >
> >
> >
> >
> >
> > RIP 35 queue service framework(QSF)
> >
> > Status
> >
> > ● Current State: Proposed
> >
> > ● Authors: booom( booom (jason) · GitHub)
> >
> > ● Shepherds: yukon( zhouxinyu (yukon) · GitHub)
> >
> > ● Mailing List discussion: dev@rocketmq.apache.org
> >
> > ● Pull Request:
> >
> > ● Released:
> >
> > Background  Motivation
> >
> > What do we need to do
> >
> > ● Will we add a new module? Yes.
> >
> > ● Will we add new APIs? No.
> >
> > ● Will we add new feature? Yes.
> >
> > Why should we do that
> >
> > ● Are there any problems of our current project?
> >
> > The current mq client API is intrusive, to send message or consume
> > message, we should code to manage the mq infrastructure, and mixed it up
> > with our business logic codes.
> >
> > ● What can we benefit proposed changes?
> >
> > 1.  Encapsulate mq client API to support method invoking style usage.
> >
> > 2.  The encapsulation is easily extensible, to support
> > idempotence/eventually consistent/ fluid control extensions and so on.
> >
> > 3.  Isolate the mq client manage code and the business logic code, to
> > help mq users improve their systems’ maintainability.
> >
> > Goals
> >
> > ● What problem is this proposal designed to solve?
> >
> > Unobtrusive mq client usage, and easily extensible to support
> > idempotence/eventually consistent/ fluid control extensions and so on.
> >
> > ● To what degree should we solve the problem?
> >
> > 100%.
> >
> > Non-Goals
> >
> > ● What problem is this proposal NOT designed to solve?
> >
> > 1.  Add new features to classics mq client.
> >
> > 2.  Affect compatibility.
> >
> > ● Are there any limits of this proposal?
> >
> > Only QSF(queue service framework) users will benefit.
> >
> > Changes
> >
> > Architecture
> >
> > To simplify a process, we need to consider what information is essential
> > and must be provided by users to execute this process? How to properly
> > organize this information so that it is most user-friendly?
> >
> >
> > Along this thinking path, we have extracted the necessary parameters for
> > mq calls and organized them into the java annotations @QSFConsumer and
> > @QSFProvider. After that, through the extension support of spring
> container
> > in each stage of bean life cycle, we can process @QSFConsumer
> @QSFProvider
> > annotation in BeanPostProcessor, extract method invocation information to
> > method invocation information object MethodInvokeInfo and send it out,
> and
> > locate it through MethodInvokeInfo at the message receiving endpoint. The
> > bean where the call is made, the method where it is located, the
> parameters
> > used, and then the method is called by reflection.
> >
> >
> >
> >
> >
> > Interface Design/Change
> >
> > ● Method signature changes
> >
> > ○   method name
> >
> > ○   parameter list
> >
> > ○   return value
> >
> > Nothing.
> >
> > ● Method behavior changes
> >
> > Nothing.
> >
> > ● CLI command changes
> >
> > Nothing.
> >
> > ● Log format or content changes
> >
> > Nothing.
> >
> > Compatibility, Deprecation, and Migration Plan
> >
> > ● Are backward and forward compatibility taken into
> > consideration?
> >
> > Yes.
> >
> > ● Are there deprecated APIs?
> >
> > Nothing.
> >
> > ● How do we do migration?
> >
> > Upgrade normally, no additional migration required.
> >
> > Implementation Outline
> >
> > We will implement the proposed changes by 1 phase. (QSF is implemented
> and
> > works well in our project)
> >
> > Phase 1
> >
> >
> > Complete the QSF mq client encapsulation.
> >
> >
> >
> > Complete the QSF idempotency support
> >
> >
> > Rejected Alternatives
> >
> > There are no other alternatives.
> >
> >
> >
> >
> >
> >
> >
> > --原始邮件--
> > 发件人:
> >   "Jason.Chen"
> >   <
> > chenhua...@foxmail.com;
> > 发送时间:2022年3月16日(星期三) 中午12:55
> > 收件人:"dev" >
> > 主题:[DISCUSS] RIP-35 queue service framework(QSF)
> >
> >
> >
> >
> >
> >
> >
> > Status
> >
> > ●  Current State: Proposed
> >
> > ●  Authors: booom( booom (jason) · GitHub)
> >
> > ●  Shepherds: yukon( zhouxinyu (yukon) · 

Re: [VOTE][RIP-36] Optimize topic routing mechanism

[heng du]

+1

git_yang  于2022年3月14日周一 16:47写道：

> +1
>
>
> | |
> git_yang
> |
> |
> git_y...@163.com
> |
> 签名由网易邮箱大师定制
>
>
> On 03/14/2022 14:02，jinrongtong wrote：
> +1
> At 2022-03-12 14:19:35, "yuzhou"  wrote:
> +1
>
> On 2022/03/02 11:42:14 xijiu wrote:
> Hi, RocketMQ Community,
>
> As discussed in the previous email, we launched a new RIP to optimize
> topic routing mechanism. Now the shepherds @dongeforever and @yukon are
> willing to support the RIP, so I think it is time to start an email thread
> to enter the voting process.
>
>
> The vote will be open for at least 72 hours or until a necessary number of
> votes are reached.
>
> Please vote accordingly:
>
> [ ] +1 approve
> [ ] +0 no opinion
> [ ] -1 disapprove with the reason
>
>
> Best Regards!
> xijiu
>
> links:
> https://shimo.im/docs/vVAXVrDNnoSrMBqm/
>

Re: [RESTART][VOTE]Release Apache RocketMQ 5.0.0-ALPHA RC2

[heng du]

+1
[ok]  Checksums and PGP signatures are valid for Source package.
[ok]   Checksums and PGP signatures are valid for Binary package.
[ok]  Source code artifacts have correct names matching the current release.
[ok]   Binary artifacts have correct names matching the current release.
[ok]   License and Notice are correct in source package.
[ok]  License and Notice are correct in binary package.
[ok]  All files have license headers in source package if necessary.
[ok]  No compiled archives bundled in source archive.
[ok]  Hash and Tag in GitHub repo is matching the current artifacts.
[ok]   The code can be built success in the source package.
[ok]  Start nameserver and broker according to the quick-start
[ok]  Run clusterList command to see if the version is correct

jinrongtong  于2022年3月11日周五 11:44写道：

> Hello RocketMQ Community,
>
> This is the vote for 5.0.0-alpha rc2 of Apache RocketMQ.
> This release contains some important new features, including static topic
> and batch consume queue.
>
> The artifacts:
> https://dist.apache.org/repos/dist/dev/rocketmq/5.0.0-ALPHA-rc2/
>
> The staging repo:
> https://repository.apache.org/content/repositories/orgapacherocketmq-1083
>
> Git tag for the release:
> https://github.com/apache/rocketmq/tree/5.0.0-alpha
> 
>
> Hash for the release tag:
> a17fa7605cfbd266e4468e6fe2d6cf6711572111
>
> Release Notes:
> https://rocketmq.apache.org/release_notes/release-notes-5.0.0-ALPHA/
> 
>
> The artifacts have been signed with Key
> EC9F268B4C20590138B11FE701420E4292296EAE, which can be found in the keys
> file:
> https://dist.apache.org/repos/dist/dev/rocketmq/KEYS
>
>
> Checklist for reference,
> Note that this is not an official policy but may help with checking
> releases.
> Fill in the following:
>
> []  Checksums and PGP signatures are valid for Source package.
> []  Checksums and PGP signatures are valid for Binary package.
> []  Source code artifacts have correct names matching the current release.
> []  Binary artifacts have correct names matching the current release.
> []  License and Notice are correct in source package.
> []  License and Notice are correct in binary package.
> []  All files have license headers in source package if necessary.
> []  No compiled archives bundled in source archive.
> []  Hash and Tag in GitHub repo is matching the current artifacts.
> []  The code can be built success in the source package.
> []  Start nameserver and broker according to the quick-start
> []  Run clusterList command to see if the version is correct
>
> And any other check point is welcomed and please feel free to reply to
> this email, we sincerely hope to your feedback.
> The vote will be open for at least 72 hours or until necessary number of
> votes are reached.
>
> Please vote accordingly:
>
> [ ] +1 approve
> [ ] +0 no opinion
> [ ] -1 disapprove with the reason
>
>
> Thanks,
> The Apache RocketMQ Team
>
>
>
>

Re: [VOTE]Release Apache RocketMQ 5.0.0-ALPHA RC1

[heng du]

-1
Version is not correct.
[image: image.png]

heng du  于2022年3月10日周四 21:44写道：

> +1
> checked:
> [OK]  Checksums and PGP signatures are valid for Source package.
> [OK]  Checksums and PGP signatures are valid for Binary package.
> [OK]  Source code artifacts have correct names matching the current
> release.
> [OK]  Binary artifacts have correct names matching the current release.
> [OK]  License and Notice are correct in source package.
> [OK]  License and Notice are correct in binary package.
> [OK]  All files have license headers in source package if necessary.
> [OK]  No compiled archives bundled in source archive.
> [OK]  Hash and Tag in GitHub repo is matching the current artifacts.
> [OK]  The code can be built success in the source package.
> [ok]  The code can be built success in the source package.
> [ok]  Start nameserver and broker according to the quick-start
> [ok]  Run clusterList command to see if the version is correct
>
> ShannonDing  于2022年3月9日周三 10:57写道：
>
>> +1,
>> Use Git tag for the release link:
>> https://github.com/apache/rocketmq/tree/5.0.0-alpha
>>
>>
>>
>>
>> checked:
>> [OK]  Checksums and PGP signatures are valid for Source package.
>> [OK]  Checksums and PGP signatures are valid for Binary package.
>> [OK]  Source code artifacts have correct names matching the current
>> release.
>> [OK]  Binary artifacts have correct names matching the current release.
>> [OK]  License and Notice are correct in source package.
>> [OK]  License and Notice are correct in binary package.
>> [OK]  All files have license headers in source package if necessary.
>> [OK]  No compiled archives bundled in source archive.
>> [OK]  Hash and Tag in GitHub repo is matching the current artifacts.
>> [OK]  The code can be built success in the source package.
>>
>>
>>
>> At 2022-03-08 17:14:45, "jinrongtong"  wrote:
>>
>> Hello RocketMQ Community,
>>
>> This is the vote for 5.0.0-alpha of Apache RocketMQ.
>>
>> This release contains some important new features, including static topic
>> and batch consume queue.
>>
>>
>> The artifacts:
>> https://dist.apache.org/repos/dist/dev/rocketmq/5.0.0-ALPHA-rc1/
>>
>>
>> The staging repo:
>> https://repository.apache.org/content/repositories/orgapacherocketmq-1082
>>
>>
>> Git tag for the release:
>> https://github.com/apache/rocketmq/tree/5.0.0-alpha
>>
>>
>> Hash for the release tag:
>> be750f0e3340aea15c38368b3542888a5f40b8d9
>>
>>
>> Release Notes:
>> https://rocketmq.apache.org/release_notes/release-notes-5.0.0-ALPHA/
>>
>>
>> The artifacts have been signed with Key
>> EC9F268B4C20590138B11FE701420E4292296EAE, which can be found in the keys
>> file:
>> https://dist.apache.org/repos/dist/dev/rocketmq/KEYS
>>
>>
>>
>>
>> Checklist for reference,
>> Note that this is not an official policy but may help with checking
>> releases.
>> Fill in the following:
>>
>>
>> []  Checksums and PGP signatures are valid for Source package.
>> []  Checksums and PGP signatures are valid for Binary package.
>> []  Source code artifacts have correct names matching the current release.
>> []  Binary artifacts have correct names matching the current release.
>> []  License and Notice are correct in source package.
>> []  License and Notice are correct in binary package.
>> []  All files have license headers in source package if necessary.
>> []  No compiled archives bundled in source archive.
>> []  Hash and Tag in GitHub repo is matching the current artifacts.
>> []  The code can be built success in the source package.
>> []  Start nameserver and broker according to the quick-start
>> []  Run clusterList command to see if the version is correct
>>
>>
>> And any other check point is welcomed and please feel free to reply to
>> this email, we sincerely hope to your feedback.
>> The vote will be open for at least 72 hours or until necessary number of
>> votes are reached.
>>
>>
>> Please vote accordingly:
>>
>>
>> [ ] +1 approve
>> [ ] +0 no opinion
>> [ ] -1 disapprove with the reason
>>
>>
>>
>>
>> Thanks,
>> The Apache RocketMQ Team
>>
>>
>>
>>
>>
>
>

Re: [VOTE]Release Apache RocketMQ 5.0.0-ALPHA RC1

[heng du]

+1
checked:
[OK]  Checksums and PGP signatures are valid for Source package.
[OK]  Checksums and PGP signatures are valid for Binary package.
[OK]  Source code artifacts have correct names matching the current release.
[OK]  Binary artifacts have correct names matching the current release.
[OK]  License and Notice are correct in source package.
[OK]  License and Notice are correct in binary package.
[OK]  All files have license headers in source package if necessary.
[OK]  No compiled archives bundled in source archive.
[OK]  Hash and Tag in GitHub repo is matching the current artifacts.
[OK]  The code can be built success in the source package.
[ok]  The code can be built success in the source package.
[ok]  Start nameserver and broker according to the quick-start
[ok]  Run clusterList command to see if the version is correct

ShannonDing  于2022年3月9日周三 10:57写道：

> +1,
> Use Git tag for the release link:
> https://github.com/apache/rocketmq/tree/5.0.0-alpha
>
>
>
>
> checked:
> [OK]  Checksums and PGP signatures are valid for Source package.
> [OK]  Checksums and PGP signatures are valid for Binary package.
> [OK]  Source code artifacts have correct names matching the current
> release.
> [OK]  Binary artifacts have correct names matching the current release.
> [OK]  License and Notice are correct in source package.
> [OK]  License and Notice are correct in binary package.
> [OK]  All files have license headers in source package if necessary.
> [OK]  No compiled archives bundled in source archive.
> [OK]  Hash and Tag in GitHub repo is matching the current artifacts.
> [OK]  The code can be built success in the source package.
>
>
>
> At 2022-03-08 17:14:45, "jinrongtong"  wrote:
>
> Hello RocketMQ Community,
>
> This is the vote for 5.0.0-alpha of Apache RocketMQ.
>
> This release contains some important new features, including static topic
> and batch consume queue.
>
>
> The artifacts:
> https://dist.apache.org/repos/dist/dev/rocketmq/5.0.0-ALPHA-rc1/
>
>
> The staging repo:
> https://repository.apache.org/content/repositories/orgapacherocketmq-1082
>
>
> Git tag for the release:
> https://github.com/apache/rocketmq/tree/5.0.0-alpha
>
>
> Hash for the release tag:
> be750f0e3340aea15c38368b3542888a5f40b8d9
>
>
> Release Notes:
> https://rocketmq.apache.org/release_notes/release-notes-5.0.0-ALPHA/
>
>
> The artifacts have been signed with Key
> EC9F268B4C20590138B11FE701420E4292296EAE, which can be found in the keys
> file:
> https://dist.apache.org/repos/dist/dev/rocketmq/KEYS
>
>
>
>
> Checklist for reference,
> Note that this is not an official policy but may help with checking
> releases.
> Fill in the following:
>
>
> []  Checksums and PGP signatures are valid for Source package.
> []  Checksums and PGP signatures are valid for Binary package.
> []  Source code artifacts have correct names matching the current release.
> []  Binary artifacts have correct names matching the current release.
> []  License and Notice are correct in source package.
> []  License and Notice are correct in binary package.
> []  All files have license headers in source package if necessary.
> []  No compiled archives bundled in source archive.
> []  Hash and Tag in GitHub repo is matching the current artifacts.
> []  The code can be built success in the source package.
> []  Start nameserver and broker according to the quick-start
> []  Run clusterList command to see if the version is correct
>
>
> And any other check point is welcomed and please feel free to reply to
> this email, we sincerely hope to your feedback.
> The vote will be open for at least 72 hours or until necessary number of
> votes are reached.
>
>
> Please vote accordingly:
>
>
> [ ] +1 approve
> [ ] +0 no opinion
> [ ] -1 disapprove with the reason
>
>
>
>
> Thanks,
> The Apache RocketMQ Team
>
>
>
>
>

Re: [VOTE]: Release Apache RocketMQ 4.9.3 RC1

[heng du]

+1
I checked：
[OK] Hash and Tag in GitHub repo is matching the current artifacts.
[OK]  Checksums and PGP signatures are valid for Source package.
[OK]  Checksums and PGP signatures are valid for Binary package.
[OK]  Source code artifacts have correct names matching the current release.
[OK] All UT can pass
[OK] Run cluster list command to see if the version is correct
[OK] Start nameserver and broker according to the quick-start


Rongtong Jin  于2022年2月23日周三 20:36写道：

> +1
> I Checked
>
> [OK] Hash and Tag in GitHub repo is matching the current artifacts.
> [OK]  Checksums and PGP signatures are valid for Source package.
> [OK]  Checksums and PGP signatures are valid for Binary package.
> [OK]  Source code artifacts have correct names matching the current
> release.
> [OK] All UT can pass
>
>
> 2022-02-23 15:02:22"tiger lee" 写道：
>
> Hello RocketMQ Community,
>
> This is the vote for 4.9.3 RC1 of Apache RocketMQ.
> This release is to improve some features and issues for apache
> rocketmq,such as support for Multiple Directories Storage, improve
> performances, fix some bugs and issues and so on.
>
> The artifacts:
> https://dist.apache.org/repos/dist/dev/rocketmq/4.9.3-rc1/
>
> The staging repo:
> https://repository.apache.org/content/repositories/orgapacherocketmq-1081
>
> Git tag for the release:
> https://github.com/apache/rocketmq/releases/tag/rocketmq-all-4.9.3
>
> Hash for the release tag:
> c7989f85744e65e24b43955c88987288487b4707
>
> Release Notes:
> https://rocketmq.apache.org/release_notes/release-notes-4.9.3
>
> The artifacts have been signed with Key :
> F32A2D46, which can be found in the keys file:
> https://dist.apache.org/repos/dist/dev/rocketmq/KEYS
>
>
> The vote will be open for at least 72 hours or until the necessary number
> of votes are reached.
> Please vote accordingly:
>
> [ ] +1 approve
> [ ] +0 no opinion
> [ ] -1 disapprove with the reason
>
> Thanks
> The Apache RocketMQ Team
>
>

Re: [DISCUSS] RIP-36 Optimize topic routing mechanism

[heng du]

+1

老康 <422766...@qq.com.invalid> 于2022年2月23日周三 21:04写道：

> Hello, everyone
>
>
> https://shimo.im/docs/vVAXVrDNnoSrMBqm/
>
>
> The above link is the RIP that optimized topic routing mechanism, please
> check.If you have any suggestions please reply to this email.
>
>
>
>
> Regards，
> xijiu

Re: [DISCUSS] Prepare to release Apache RocketMQ 5.0.0-alpha

[heng du]

Looking forward to an early release.

jinrongtong  于2022年2月21日周一 16:42写道：

> Hi, everyone
>
> I hope you’ve all been doing well. It's been a while since RocketMQ
> 5.0.0-Preview was released. During this time a number of new features were
> developed in the 5.0.0-alpha branch, including static topic[1] and batch
> consume queue[2]. I think it is time to release RocketMQ 5.0.0-alpha. So I
> would like to start an email thread to discuss the plan to release Apache
> RocketMQ 5.0.0-alpha.
>
> If you have any suggestions please reply to this email.
>
>
>
> Regards，
> RongtongJin
>
>
> [1]https://github.com/apache/rocketmq/tree/5.0.0-alpha/docs/cn/statictopic
> [2]
> https://github.com/apache/rocketmq/wiki/RIP-26-Improve-Batch-Message-Processing-Throughput

Re: [VOTE] [RIP-35]Use rocketmq instead of mysql as state store

[heng du]

+1

yukon  于2022年2月18日周五 10:25写道：

> +1 to minimize the dependencies.
>
> On Fri, Feb 18, 2022 at 10:07 AM Amber Liu  wrote:
>
> > +1 (non-binding)
> >
> > nize  于2022年2月18日周五 10:06写道：
> >
> > > Hi, RocketMQ Community,
> > >
> > > As discussed in the previous email, we launched a new RIP to replace
> > mysql
> > > with RocketMQ as a state store in RocketMQ-streams.Now the
> > > shepherd @duhenglucky and @von Gosling is willing to support the RIP,
> so
> > I
> > > think it is time to start an email thread to enter the voting process.
> > >
> > > The vote will be open for at least 72 hours or until a necessary number
> > of
> > > votes are reached.
> > >
> > > Please vote accordingly:
> > > [ ] +1 approve
> > > [ ] +0 no opinion
> > > [ ] -1 disapprove with the reason
> > >
> > > Best Regards!
> > >
> > > links
> > >
> > >
> >
> https://docs.google.com/document/d/1gmwU4rC5wyG07R55jW5oN4GzxHSq8QoFNdoNL61xT0M/edit?usp=sharing
> > >
> >
>

Re: Re: [VOTE][RIP-34] Support quorum write and adaptive degradation in master-slave architecture

[heng du]

+1

Rongtong Jin  于2022年2月12日周六 20:29写道：

> Yes, In this thread
> https://lists.apache.org/thread/nyfhfmz1zfvp9kpvwbj6qbd5988932rl
> You can say your doubts directly
>
> Zhanhui Li lizhan...@apache.org写道：
> > Is there any discussion thread prior to this RIP? I got a few doubts to
> > clarify in terms of how auto degradation is supposed to work.
> >
> > On Sat, Feb 12, 2022 at 10:48 AM jinrongtong 
> wrote:
> >
> > > Hi, RocketMQ Community,
> > >
> > > As discussed in the previous email, we launched a new RIP to support
> > > quorum write and adaptive degradation in master-slave architecture.
> Now the
> > > shepherd @duhenglucky is willing to support the RIP, so I think it is
> time
> > > to start an email thread to enter the voting process.
> > >
> > > The vote will be open for at least 72 hours or until a necessary
> number of
> > > votes are reached.
> > >
> > > Please vote accordingly:
> > >
> > > [ ] +1 approve
> > > [ ] +0 no opinion
> > > [ ] -1 disapprove with the reason
> > >
> > >
> > > Best Regards!
> > > Rongtong Jin
> > >
> > >
> > > links:
> > >
> > >
> https://docs.google.com/document/d/1ENCJl83OGnmtPMAbxTqtEs9LOOIkMNkz3A9HZJHyI2o/edit?usp=sharing
> > > https://shimo.im/docs/WJptDyXgjc3h6C8R
>

[RESULT] [VOTE] Creating an external logappender repository

[heng du]

Hello RocketMQ Community,

This is the vote result for Creating an external logappender repository,
and it has been passed with [3] binding +1s, [6] non-bindings:

*Binding votes +1s:*

RongtongJin
ShannonDing
dongeforever


*Non-binding votes +1s:*
Yu Kvicii
zhibo li
倪泽
yuzhou
caigy
Amber Liu



Thanks,
Heng Du







Amber Liu  于2022年2月13日周日 12:27写道：

> +1
>
> heng du  于2022年2月8日周二 16:40写道：
>
> > Dear community,
> >
> > This is the vote for moving the logappender[1] to the
> rocketmq-externals[2]
> > repo first because it seems that logappender has little to do with the
> core
> > of Apache RocketMQ, and it can bring faster releases of logappender,
> > decouple with the release cycles of Apache RocketMQ.
> >
> > The vote will be open for at least 72 hours or until a necessary number
> of
> > votes are reached.
> >
> >
> > Please vote accordingly:
> > [ ] +1 approve
> > [ ] +0 no opinion
> > [ ] -1 disapprove with the reason
> >
> > [1] https://github.com/apache/rocketmq
> > [2] https://github.com/apache/rocketmq-externals
> >
> >
> >
> > Thanks
> > Henry
> >
> > heng du  于2022年1月21日周五 14:49写道：
> >
> > > Hi， Justin，
> > > Thanks for your kindly reply,  sorry I didn't express it clearly, and
> we
> > > do not intend to move this project out of the apache repository, but
> just
> > > transfer it from the main repository[1] to another sub-repository of
> > apache
> > > rocketmq[2]， there should be no IP and ICLA issues involved.
> > >
> > > [1] https://github.com/apache/rocketmq
> > > [2] https://github.com/apache/rocketmq-externals
> > >
> > > Thanks
> > > Henry
> > >
> > > Justin Mclean  于2021年12月17日周五 11:36写道：
> > >
> > >> Hi,
> > >>
> > >> I would consider this very carefully and in fact suggest that you
> don’t
> > >> do this. Work on ASF projects needs to happen in ASF repos. By doing
> it
> > >> outside you are missing the legal protection the ASF gives you and
> other
> > >> benefits being inside an ASF project give yuo. If at a later point it
> > does
> > >> need to be brought back then you may have issues with IP and ICLAs.
> > >>
> > >> Kind Regards,
> > >> Justin
> > >
> > >
> >
>

Re: [VOTE][RIP-33] RocketMQ MQTT

[heng du]

+1

Rongtong Jin  于2022年2月9日周三 19:34写道：

> +1, really looking forward to
>
> Ping Wang pingw...@gmail.com写道：
> > Hi, RocketMQ Community,
> >
> > As discussed in the previous email, we launched a new RIP to support MQTT
> > protocol. Now the shepherd @duhenglucky is willing to support the RIP,
> so I
> > think it is time to start an email thread to enter the voting process.
> >
> > The vote will be open for at least 72 hours or until a necessary number
> of
> > votes are reached.
> >
> > Please vote accordingly:
> > [ ] +1 approve
> > [ ] +0 no opinion
> > [ ] -1 disapprove with the reason
> >
> >
> > Best Regards!
> > Ping Wang
> >
> >
> > links:
> >
> >
> https://docs.google.com/document/d/1AD1GkV9mqE_YFA97uVem4SmB8ZJSXiJZvzt7-K6Jons/edit#heading=h.i42fwfxz62gw
>

Re: [DISCUSS][RIP-35] Use rocketmq instead of mysql as state store

[heng du]

Great, this RIP not only removes database dependencies, but also provides
best practices for state storage in RocketMQ

倪泽  于2022年2月9日周三 17:38写道：

> Hi, RocketMQ Community,
>
> First of all, Happy Chinese New Year!
> I want to start a RIP to replace mysql with RocketMQ as state store in
> RocketMQ-streams. Base the RocketMQ storage, I will provide a exactly-once
> supported and efficient state storage scheme.
>
> I have written my proposal and you can click on the link below：
>
>
> https://docs.google.com/document/d/1gmwU4rC5wyG07R55jW5oN4GzxHSq8QoFNdoNL61xT0M/edit?usp=sharing
>
> Chinese version：
>
> https://shimo.im/docs/pjDRKHqtdQC9RWCg
>
> If you have any questions or suggestions, please reply to this email or
> comment on the proposal.
>
>
> Thanks
> Nize
>

[VOTE] RIP-25 Ease of Use Improvements on RocketMQ Client API

[heng du]

+1

caigy  于2021年9月28日周二 17:41写道：

> RIP-25 Ease of Use Improvements on RocketMQ Client API
>
>
>   * Current Status: Draft
>   * Authors: caigy https://github.com/caigy
>   * Shepherds: duhengforever duhengfore...@apache.org
>   * Mailing List discussion: dev@rocketmq.apache.org
>   * Pull Request: #PR_NUMBER
>   * Released: 
>
>
> Background & Motivation
> 
>
> What do we need to do
>  * will we add a new module? No.
>  * will we add new APIs? Yes.
>  * will we add new feature? No.
>
>
> Why should we do that
>  * Are there any problems of our current project?
> Currently, RocketMQ's client API is a bit complex, and there exists
> some unreasonable encapsulation. For example:
> ** There are 20 methods for sending messages in DefaultProducer, with
> lack of encapsulation, which increases complexity in usage.
> ** DefaultMQPushConsumer provides 10 constructors，which may make user
> difficult to choose one.
> ** Class Message provides constructors with and without arguments, and
> also provides getters/setters to operate fields of it,  which lacks good
> separation of required and non-required arguments.
> API is important media for users to interact with RocketMQ, and it is
> worth investing effort in optimizing its design.
>
> * What can we benefit proposed changes?
> Provide clear and easier-to-understand API of RocketMQ, make it easier
> to use, especially for beginners.
>
>
>
> Goals
> 
>
> * What problem is this proposal designed to solve?
>Optimize RocketMQ client APIs, including Producer, Consumer and
> Message, remove unnecessary APIs, and provide better encapsulation. Current
> unreasonable APIs will be marked deprecated and will be removed in the
> future. After this optimization, the APIs should keep as stable as possible.
>
> * To what degree should we solve the problem?
> We wish developers can use RocketMQ more easily with new APIs.
>
>
> Non-Goals
> 
>
> * What problem is this proposal NOT designed to solve?
>This proposal will NOT change feature and performance.
>
> * Are there any limits of this proposal?
>   Nothing specific.
>
>
>
> Changes
> 
>
> * Architecture
>  No architecture changes in this proposal.
>
> * Interface Design/Change
>** Method signature changes. Yes.
>For example:
>*** Add generic to support data type of message body in Message.
>*** Support chain-call instantiation of Producer, Consumer,
> Message, eg：Message.builder().topic("msg  topic").body("msg
> body").build();
>*** Producer provides unified and stable send() API, which is like
> write() method of UNIX file I/O.
>*** Add asynchronous message consumption API based on
> CompletableFuture in Consumer.
>*** etc...
>
>** Method behavior changes. No.  CLI command changes. No.
>** Log format or content changes. No.
>
> * Compatibility, Deprecation, and Migration Plan
>** Are backward and forward compatibility taken into consideration?
>   Optimized APIs should NOT affect compatibility, some APIs would be
> marked deprecated. New features will use optimized APIs, encouraging users
> not to use deprecated APIs.
>
>** Are there deprecated APIs?
>   Yes. Some unreasonable APIs will be deprecated in this RIP.
>
>   ** How do we do migration?
>   Unreasonable APIs are marked deprecated in this proposal, and will
> be removed in the future.
>
> * Implementation Outline
>   We will implement the proposed changes by 1 phase.
>   Phase 1
>  1. Collect pain points in using RocketMQ client APIs and redesign
> them.
>  2. Optimize those APIs.
>  3. Mark previous APIs deprecated.
>
>

[VOTE] Creating an external logappender repository

[heng du]

Dear community,

This is the vote for moving the logappender[1] to the rocketmq-externals[2]
repo first because it seems that logappender has little to do with the core
of Apache RocketMQ, and it can bring faster releases of logappender,
decouple with the release cycles of Apache RocketMQ.

The vote will be open for at least 72 hours or until a necessary number of
votes are reached.


Please vote accordingly:
[ ] +1 approve
[ ] +0 no opinion
[ ] -1 disapprove with the reason

[1] https://github.com/apache/rocketmq
[2] https://github.com/apache/rocketmq-externals



Thanks
Henry

heng du  于2022年1月21日周五 14:49写道：

> Hi， Justin，
> Thanks for your kindly reply,  sorry I didn't express it clearly, and we
> do not intend to move this project out of the apache repository, but just
> transfer it from the main repository[1] to another sub-repository of apache
> rocketmq[2]， there should be no IP and ICLA issues involved.
>
> [1] https://github.com/apache/rocketmq
> [2] https://github.com/apache/rocketmq-externals
>
> Thanks
> Henry
>
> Justin Mclean  于2021年12月17日周五 11:36写道：
>
>> Hi,
>>
>> I would consider this very carefully and in fact suggest that you don’t
>> do this. Work on ASF projects needs to happen in ASF repos. By doing it
>> outside you are missing the legal protection the ASF gives you and other
>> benefits being inside an ASF project give yuo. If at a later point it  does
>> need to be brought back then you may have issues with IP and ICLAs.
>>
>> Kind Regards,
>> Justin
>
>

Re: [VOTE][RIP-32] Slave Acting Master Mode

[heng du]

+1

jinrongtong  于2022年2月3日周四 00:03写道：

> Hi, RocketMQ Community,
>
> As discussed in the previous email, we launched a new RIP to support slave
> acting master mode. Now the shepherd @duhenglucky is willing to support the
> RIP, so I think it is time to start an email thread to enter the voting
> process.
>
>
> The vote will be open for at least 72 hours or until a necessary number of
> votes are reached.
>
>
> Please vote accordingly:
> [ ] +1 approve
> [ ] +0 no opinion
> [ ] -1 disapprove with the reason
>
>
>
>
> Best Regards!
> Rongtong Jin
>
>
>
>
> links:
>
>
> https://docs.google.com/document/d/1LCTkfem6wcV-PqWjzPAvaxgqFMCj3ymPakDrcodX9ic/edit?usp=sharing
> https://shimo.im/docs/6CqVccXgtWgXCYwv/

Re: [DISCUSS][RIP-33] RocketMQ MQTT

[heng du]

long-awaited feature

Ping Jack  于2022年1月26日周三 14:15写道：

> Hi, RocketMQ Community:
>
> I want to start a RIP to support MQTT protocol architecture model so that
> RocketMQ can better support messages from terminals such as IoT devices and
> mobile APP. Based on the RocketMQ message unified storage engine, it
> supports both MQTT terminal and server message sending and receiving.
>
> I have written my proposal and you can click on the link below：
>
>
> https://docs.google.com/document/d/1AD1GkV9mqE_YFA97uVem4SmB8ZJSXiJZvzt7-K6Jons/edit#heading=h.i42fwfxz62gw
>
>
>
> If you have any questions or suggestions, please reply to this email or
> comment on the proposal.
>
>
>
>
> Thanks
> Ping Wang
> …
>

Re: [DISSCUSS][RIP-32] Slave Acting Master Mode

[heng du]

Great improvement, whether in terms of usability or complexity of the
operation, it is a very big improvement to the master-slave architecture.

Thank,
Henry

jinrongtong  于2022年1月26日周三 11:51写道：

> Hi, RocketMQ Community:
>
> I want to start a RIP to support a slave acting master mode which enhances
> the slave capability after the master goes offline. This mode can solve the
> consumption interruption of order messages, delay messages, transaction
> messages after the master goes offline, as well as the metadata rollback
> after the master goes online again.
>
> I have written my proposal and you can click on the link below：
>
>
> https://docs.google.com/document/d/1LCTkfem6wcV-PqWjzPAvaxgqFMCj3ymPakDrcodX9ic/edit?usp=sharing
>
> Chinese version：
>
> https://shimo.im/docs/6CqVccXgtWgXCYwv/
>
>
>
> If you have any questions or suggestions, please reply to this email or
> comment on the proposal.
>
>
>
>
> Thanks
> RongtongJin

Re: [ANNOUNCE] Release Apache RocketMQ Streams 1.0.0-preview

[heng du]

A new start

周波  于2022年1月26日周三 10:52写道：

> Hi all,
>
> The Apache RocketMQ team would like to announce the release of Apache
> RocketMQ Streams 1.0.0-preview.
>
> This is the first release of Apache RocketMQ Streams.
>
> More details regarding Apache RocketMQ Streams 1.0.0-preview can be found
> at:
> https://github.com/apache/rocketmq-streams
>
> The release artifacts can be downloaded here:
>
> https://dist.apache.org/repos/dist/release/rocketmq/rocketmq-streams/1.0.0-preview/
>
> The release notes can be found here:
>
> https://github.com/apache/rocketmq-streams/releases/tag/rocketmq-streams-1.0.0-preview
>
> Thanks, The Apache RocketMQ Team
>

Re: [VOTE] Release Apache RocketMQ Streams 1.0.0-preview RC2

[heng du]

+1
I checked:
 Checksums and PGP signatures are valid for source package.
Source code artifacts have correct names matching the current release.
License and Notice are correct in source package.
All files have license headers in source package if necessary.
No compiled archives bundled in source archive.
Hash and Tag in GitHub repo are matching the current artifacts.
The code can be built success in the source package.

周波  于2022年1月18日周二 13:15写道：

> Hello RocketMQ Community,
>
>
> This is the vote for the 1.0.0-preview release of Apache RocketMQ-Streams.
>
> The artifacts:
>
> https://dist.apache.org/repos/dist/dev/rocketmq/rocketmq-streams/1.0.0-preview-rc2/
>
> The staging repo:
> https://repository.apache.org/content/repositories/orgapacherocketmq-1074
>
> Git tag for the release:
>
> https://github.com/apache/rocketmq-streams/releases/tag/rocketmq-streams-1.0.0-preview
>
> Hash for the release tag:
> ec9d3dfef8db4ce6678e2cd84f6b498b34c87523
>
> Release Notes:
>
> http://rocketmq.apache.org/release_notes/release-notes-rocketmq-streams-1.0.0-preview/
>
> The artifacts have been signed with Key :
> DA38AD870652D9961F82EDC4E2DED90716D986F7, which can be found in the keys
> file:
>
> https://dist.apache.org/repos/dist/dev/rocketmq/KEYS
>
> Checklist for reference,
> Note that this is not an official policy but may help with checking
> releases.
>
> Fill in the following:
> [ ]  Checksums and PGP signatures are valid for source package.
> [ ]  Source code artifacts have correct names matching the current release.
> [ ]  License and Notice are correct in source package.
> [ ]  All files have license headers in source package if necessary.
> [ ]  No compiled archives bundled in source archive.
> [ ]  Hash and Tag in GitHub repo are matching the current artifacts.
> [ ]  The code can be built success in the source package.
>
> And any other checkpoint is welcomed and please feel free to reply to this
> email, we sincerely hope for your feedback.
> The vote will be open for at least 72 hours or until a necessary number of
> votes are reached.
>
> Please vote accordingly:
> [ ] +1 approve
> [ ] +0 no opinion
> [ ] -1 disapprove with the reason
>
>
> Thanks,
> The Apache RocketMQ Team
>

Re: [DISCUSS] Creating an external logappender repository

[heng du]

Hi， Justin，
Thanks for your kindly reply,  sorry I didn't express it clearly, and we do
not intend to move this project out of the apache repository, but just
transfer it from the main repository[1] to another sub-repository of apache
rocketmq[2]， there should be no IP and ICLA issues involved.

[1] https://github.com/apache/rocketmq
[2] https://github.com/apache/rocketmq-externals

Thanks
Henry

Justin Mclean  于2021年12月17日周五 11:36写道：

> Hi,
>
> I would consider this very carefully and in fact suggest that you don’t do
> this. Work on ASF projects needs to happen in ASF repos. By doing it
> outside you are missing the legal protection the ASF gives you and other
> benefits being inside an ASF project give yuo. If at a later point it  does
> need to be brought back then you may have issues with IP and ICLAs.
>
> Kind Regards,
> Justin

Re: [VOTE][RIP-25] Ease of Use Improvements on RocketMQ Client API

[heng du]

+1

caigy  于2022年1月21日周五 12:02写道：

> Hi, RocketMQ Community,
>
> As discussed in the previous email, we launched a new RIP to improve ease
> of use for RocketMQ Client. Now the shepherds @duhenglucky is willing to
> support the RIP, so I think it is time to start an email thread to enter
> the voting process.
>
>
> The vote will be open for at least 72 hours or until a necessary number of
> votes are reached.
>
>
> Please vote accordingly:
>
>
> [ ] +1 approve
> [ ] +0 no opinion
> [ ] -1 disapprove with the reason
>
>
> Best Regards!
>
> links:
> https://docs.google.com/document/d/1hlwEe6jcqafEMQIiOp-dLirDad6fa7dpajAdw0JAWNs/edit?usp=sharing
>

Re: [VOTE][RIP-30] Support Compaction topic

[heng du]

+1

Ze Ni  于2022年1月21日周五 11:01写道：

> +1
>
> Amber Liu  于2022年1月21日周五 10:59写道：
>
> > Hi, RocketMQ Community,
> >
> > As discussed in the previous email[1], we launched a new RIP to Support
> > Compaction topic. Now the shepherds @duhenglucky are willing to support
> the
> > RIP, so I think it is time to start an email thread to enter the voting
> > process.
> >
> >
> > The vote will be open for at least 72 hours or until a necessary number
> of
> > votes are reached.
> >
> >
> > Please vote accordingly:
> >
> >
> > [ ] +1 approve
> > [ ] +0 no opinion
> > [ ] -1 disapprove with the reason
> >
> >
> > Best Regards!
> >
> >
> > links:
> > https://lists.apache.org/thread/bm0ov3sy96vj49vq4v3yryry7pjg9dxm
> >
>

Re: [VOTE][RIP-31] Support RocketMQ BrokerContainer

[heng du]

+1

jinrongtong  于2022年1月21日周五 10:23写道：

> Hi, RocketMQ Community,
>
> As discussed in the previous email, we launched a new RIP to support
> RocketMQ BrokerContainer. Now the shepherds @duhenglucky and @odbozhou are
> willing to support the RIP, so I think it is time to start an email thread
> to enter the voting process.
>
>
>
> The vote will be open for at least 72 hours or until a necessary number of
> votes are reached.
>
>
> Please vote accordingly:
>
>
> [ ] +1 approve
> [ ] +0 no opinion
> [ ] -1 disapprove with the reason
>
>
>
>
> Best Regards!
> Rongtong Jin
>
>
> links:
>
> https://docs.google.com/document/d/1Rnh9QSZSRowHnjMyDr7JKiHc-_uxc4ycSumbtB_iKzg/edit?usp=sharing
> https://shimo.im/docs/xxY3QDqYvj6G6Gk9/

Re: [VOTE][RIP-29] Optimize RocketMQ NameServer

[heng du]

+1

jinrongtong  于2022年1月18日周二 10:28写道：

> Hi, RocketMQ Community:
>
>
> As discussed in the previous email, we launched a new RIP to optimize
> RocketMQ nameserver. Now the shepherds @duhenglucky and @ShannonDing are
> willing to support the RIP, so I think it is time to start an email thread
> to enter the voting process.
>
> The vote will be open for at least 72 hours or until a necessary number of
> votes are reached.
>
> Please vote accordingly:
>
> [ ] +1 approve
> [ ] +0 no opinion
> [ ] -1 disapprove with the reason
>
>
>
>
> Best Regards!
> Rongtong Jin
>
>
> Proposal link: https://shimo.im/docs/pXgKrCwxhCcTwPkx/

Re: [DISCUSS][RIP-29] Optimize RocketMQ NameServer

[heng du]

+1
In the case of a large number of clients, the acquisition of routes will
gradually become a bottleneck. I agree with the use of topic caching to
reduce the pressure on the nameserver. In the sharing of manyusers, we have
seen that many users have used thread pool isolation. , so it's best to
push this change upstream for now.

jinrongtong  于2022年1月14日周五 10:43写道：

> Hi, RocketMQ Community:
>
> Nameserver is a very important component in RocketMQ cluster, which is
> used for route discovery. At present, the nameserver is stateless and
> lightweight, but it still bears a certain amount of pressure especially
> when the cluster reaches a certain scale. So I want to start a RIP to
> optimize the nameserver in RocketMQ 5.0.
>
> I want to optimize the nameserver from the following aspects
>
> 1. By separating the broker registration thread pool and the topic route
> info acquisition thread pool, we can ensure that different types of
> requests will not affect each other.
> 2. Optimize topic routing cache to speed up topic routing acquisition,
> reduce nameserver CPU pressure.
> 3. Unregister brokers in batches to speed up the broker offline.
>
> And there will be no compatibility issues in this RIP.
>
> Refer to the document for more details：
> https://shimo.im/docs/pXgKrCwxhCcTwPkx/
>
> I can not log in to Google Docs now, so I put the document on shimo and I
> will put it on Google Docs later.
>
> If you have any questions, please reply to this email or comment on the
> document.
>
>
>
> Thanks
> RongtongJin

Re: [DISCUSS] RIP-30 Support Compaction topic

[heng du]

As we discussed before， the compact topic is also a way to implement the KV
semantic storage. But everyone still has justice for the introduction of
rocksdb. From the design document, in the three more important scenarios:
metadata storage, connect and streaming, compact topic can meet the needs,
it seems that rocksdb can be used to speed up in the future

Amber Liu  于2022年1月14日周五 17:09写道：

> Status
>
>- Current Status: Draft
>- Authors: ltamber 
>
>
>- Shepherds: duhengforever 
>- Mailing List discussion: dev@rocketmq.apache.org
>
>
>- Pull Request: #PR_NUMBER
>- Released: 
>
> Background & Motivationwhat do we need to do
>
>- will we add a new module? *no*.
>- will we add new APIs? *no*.
>
>
>- will we add new feature? *yes*.
>
> Why should we do that
>
>- Are there any problems of our current project?
>
> Currently Rocketmq does not support the compation topic, which results in
> that if the application(such as connector/streams[1]
> ) uses
> messages to store state and only needs the latest state data at a certain
> time , it needs to pull all the messages from the broker, this process will
> consume a lot of time; At the same time, a lot of data is not required by
> the client. Therefore, we need a special data cleaning mechanism, which is
> to compress the same type of data (same key), and only keep the latest
> data, In this way, only a small amount of data is loaded when the
> application starts.
>
> Chinese version: Rocketmq目前还不支持compation
> topic，这导致应用如果使用消息来存储状态并且在某一时刻仅需要最新的状态数据时(例如connector/streams)
>
> 需要从服务端拉取所有的消息，这个过程会消耗大量时间，同时很多数据也不是客户端需要的，因此，我们需要一个特殊的数据清理机制，就是将相同类型的数据(相同的key)进行压缩，仅保留最新的数据，以此来达到应用启动时仅加载少量数据的诉求。
>
>- What can we benefit proposed changes?
>
> Improve the business scenarios that rocketmq can support
>
> Chinese version: 完善rocketmq能支持的业务场景
> Goals
>
>- What problem is this proposal designed to solve?
>
> Support compress topic data on server side.
>
> Chinese version: 支持服务端对topic数据进行压缩
>
>- To what degree should we solve the problem?
>
> Supports compression of topic data by time dimension and message size
> dimension
>
> Chinese version: 支持按时间维度、消息大小维度对topic数据进行压缩
> Non-Goals
>
>- What problem is this proposal NOT designed to solve?
>   Nothing specific.
>- Are there any limits of this proposal?
>   Nothing specific.
>
> ChangesArchitectureWrite
>
> The data is first written to the commitlog like ordinary messages, and then
> asynchronously written to the separate compaction log file by the report
> service.
>
> Chinese version: 数据与普通消息一样先写入commitlog，然后由reput
> service异步再写入到单独的compaction日志文件
>
> Compaction
>
>1. determine the compaction position
>2. Traverse data to generate  Map
>
>
>1. Traverse the data according to the  Map and keep only
>the latest data for the same key
>
> Chinese version:
>
>1. 先确定compaction结束位置
>2. 遍历数据生成 Map
>
>
>1. 根据 Map再遍历数据将相同key的数据仅保留最新的
>
> Index
>
> refer to
>
>
> https://github.com/apache/rocketmq/wiki/RIP-26-Improve-Batch-Message-Processing-Throughput
> Interface Design/Change
>
>- Method signature changes. *No*
>- Method behavior changes. *No*
>
>
>- CLI command changes. *No*
>- Log format or content changes. *No*
>
> Compatibility, Deprecation, and Migration Plan
>
>- Are backward and forward compatibility taken into consideration?
>
> Nothing specific.
>
>- Are there deprecated APIs?
>   Nothing specific.
>- How do we do migration?
>   Nothing specific.
>

Re: [VOTE]Release Apache RocketMQ Streams 1.0.0-Preview RC1

[heng du]

-1

There are log files in the release source package, such as: log/catalina.out

周波  于2022年1月5日周三 15:54写道：

> Hello RocketMQ Community,
>
>
> This is the vote for the 1.0.0-Preview release of Apache RocketMQ-Streams.
>
> The artifacts:
>
> https://dist.apache.org/repos/dist/dev/rocketmq/rocketmq-streams/1.0.0-Preview-rc1/
>
> The staging repo:
> https://repository.apache.org/content/repositories/orgapacherocketmq-1073
>
> Git tag for the release:
>
> https://github.com/apache/rocketmq-streams/releases/tag/rocketmq-streams-1.0.0-Preview
>
> Hash for the release tag:
> be941e25e52121064d8b34562c73469bb6d6d731
>
> Release Notes:
>
> http://rocketmq.apache.org/release_notes/release-notes-rocketmq-streams-1.0.0-Preview/
>
> The artifacts have been signed with Key :
> DA38AD870652D9961F82EDC4E2DED90716D986F7, which can be found in the keys
> file:
>
> https://dist.apache.org/repos/dist/dev/rocketmq/KEYS
>
> Checklist for reference,
> Note that this is not an official policy but may help with checking
> releases.
>
> Fill in the following:
> [ ]  Checksums and PGP signatures are valid for source package.
> [ ]  Source code artifacts have correct names matching the current release.
> [ ]  License and Notice are correct in source package.
> [ ]  All files have license headers in source package if necessary.
> [ ]  No compiled archives bundled in source archive.
> [ ]  Hash and Tag in GitHub repo are matching the current artifacts.
> [ ]  The code can be built success in the source package.
>
> And any other checkpoint is welcomed and please feel free to reply to this
> email, we sincerely hope for your feedback.
> The vote will be open for at least 72 hours or until a necessary number of
> votes are reached.
>
> Please vote accordingly:
> [ ] +1 approve
> [ ] +0 no opinion
> [ ] -1 disapprove with the reason
>
>
> Thanks,
> The Apache RocketMQ Team
>

Re: [VOTE][RIP-27] Auto batching in producer

[heng du]

+1

Rongtong Jin  于2021年12月29日周三 19:50写道：

> +1
>
> Mad 1094592...@qq.com.INVALID写道：
> > Hi RocketMQ Community,
> >
> > This is the vote for the kickoff of RIP-27 Auto Batch in producer
> >
> > RIP-26 has prepared to implement batchConsumeQueue, but the message
> needs to be packaged manually on the client side, so I want to implement an
> auto batching capability. Now the shepherds @RongtongJin are willing to
> support the RIP, so I think it is time to start an email thread to enter
> the voting process.
> >
> > The vote will be open for at least 72 hours or until a necessary number
> of votes are reached.
> > Please vote accordingly:
> >
> > [ ] +1 approve
> > [ ] +0 no opinion
> > [ ] -1 disapprove with the reason
> >
> >
> > Best Regards!
> > Guyinyou
> >
> >
> > RIP-27 Auto batching in producer
> >
> https://docs.google.com/document/d/1ydZrA-FNrjM52I4H72EM2yaNAEYpRHV5uUSmFgxhWUQ/edit#heading=h.l32rlf9jfklr
>

Re: [VOTE][RIP-28] light message queue (LMQ)

[heng du]

+1

田六合 <643422...@qq.com.invalid> 于2021年12月29日周三 11:56写道：

> Hi RocketMQ Community,
>
> This is the vote for the kickoff of RIP-28 light message queue(LMQ)
>
> As discussed in the previous email , we launched a new RIP to
> supportlight message queue（LMQ）, the implementation of LMQ's
> queue model is required in some messaging scenarios such as AMQP 
> MQTT. Now the shepherds @RongtongJin are willing to support the RIP, so I
> think it is time to start an email thread to enter the voting process.
>
> The vote will be open for at least 72 hours or until a necessary number of
> votes are reached.
> Please vote accordingly:
>
> [ ] +1 approve
> [ ] +0 no opinion
> [ ] -1 disapprove with the reason
>
>
> Best Regards!
> tianliuliu
>
>
> RIP-28 light message queue(LMQ)
>
> https://docs.google.com/document/d/1wq7crKF67fWv5h13TPHtCpHs-B9X8ZmaA-RM6yVbVbY/edit#

Re: Thank RocketMQ community for its contribution and look forward to more community cooperation in the future

[heng du]

I am very happy to see that the two communities have not only completed the
preparation of a Meetup together, but also completed the development of
APISIX's rocketmq-logger plug-in with high quality in such a short time.
This is not just the beginning of good cooperation between the two
communities. , but also an interpretation of the Apache way.

Thanks again,  @Ming Wen @Yeliang Wang, @ZhouYu @jing li,  I hope more
developers can pay attention to the two projects and bring more
cooperation:)

Thanks
Henry


jing li  于2021年12月20日周一 15:57写道：

> Thanks very much to duheng & yuzhou & RocketMQ community.
> Hope you will like the gifts from our community!
>
> On Mon, Dec 20, 2021 at 1:42 PM Ming Wen  wrote:
>
>> great work between Apache TLPs, thanks for the Apache RocketMQ community
>>
>> Thanks,
>> Ming Wen, Apache APISIX PMC Chair
>> Twitter: _WenMing
>>
>>
>> yeliang wang  于2021年12月20日周一 10:39写道：
>>
>> > Hi, duheng & yuzhou & RocketMQ community,
>> >
>> > Last month, Apache APISIX community planned to hold an online
>> conference in
>> > December and invited Apache RocketMQ community to participate. I'm glad
>> > Apache RocketMQ community accepted the invitation.
>> >
>> >
>> > After, the joint efforts of APISIX community and RocketMQ community, we
>> > have completed the following contents together:
>> >
>> >1. The development of rocketmq-logger plugin has been completed（
>> >https://github.com/apache/apisix/pull/5743 )
>> >2. Output the technology blog together and share it with more
>> developers
>> >3. Jointly carry out publicity activities on official websites and
>> media
>> >channels
>> >
>> >
>> > Through these efforts, we can not only meet the diversified needs of
>> users,
>> > but also enrich the surrounding ecology of Apache RocketMQ and Apache
>> > APISIX.
>> >
>> > Special thanks to @ Heng Du< duhengfore...@apache.org >With @ Zhou Yu<
>> > 845238...@qq.com >Promotion and contribution of (RocketMQ community
>> gift
>> > is
>> > on the way…)
>> >
>> > We look forward to more community cooperation in the future.
>> >
>> > Thanks,
>> > Github: wang-yeliang, Twitter: @WYeliang
>> >
>>
>

Re: [DISCUSS] Creating an external logappender repository

[heng du]

Dear community,

Today I would like to kickstart a series of discussions around creating an
external logappender[1] repository. , and maybe It is recommended to put it
in the rocketmq-externals[2] repo first because it seems that logappender
has little to do with the core of Apache RocketMQ, and it can bring faster
releases of logappender, decouple with the release cycles of Apache
RocketMQ.

Now I’d first like to collect your viewpoints on this discussion, please
feel free to reply to this email if you have any other points.


[1] https://github.com/apache/rocketmq/tree/master/logappender
[2] https://github.com/apache/rocketmq-externals

Thanks
Henry


heng du  于2021年12月16日周四 22:17写道：

> Dear community,
>
> Today I would like to kickstart a series of discussions around creating an
> external logappender[1] repository. , and maybe It is recommended to put
> it in the rocketmq-externals[2] repo first because it seems that
> logappender has little to do with the core of Apache RocketMQ, and it can
> bring faster releases of logappender, decouple with the release cycles of
> Apache RocketMQ.
>
> Now I’d first like to collect your viewpoints on this discussion, please
> feel free to reply to this email if you have any other points.
>
> Thanks
> Henry
>

[DISCUSS] Creating an external logappender repository

[heng du]

Dear community,

Today I would like to kickstart a series of discussions around creating an
external logappender[1] repository. , and maybe It is recommended to put it
in the rocketmq-externals[2] repo first because it seems that logappender
has little to do with the core of Apache RocketMQ, and it can bring faster
releases of logappender, decouple with the release cycles of Apache
RocketMQ.

Now I’d first like to collect your viewpoints on this discussion, please
feel free to reply to this email if you have any other points.

Thanks
Henry

Re: [ANNOUNCE]New Committers of Apache RocketMQ: Yang Zhang(Git-Yang)

[heng du]

Congrats!

Hu Zongtang  于2021年11月30日周二 下午2:37写道：

>
> Congrats, good guys!
> --
> *发件人:* jinrongto...@163.com  代表 jinrongtong <
> jinrongt...@apache.org>
> *发送时间:* 2021年11月30日 11:27
> *收件人:* us...@rocketmq.apache.org ;
> dev@rocketmq.apache.org 
> *主题:* [ANNOUNCE]New Committers of Apache RocketMQ: Yang Zhang(Git-Yang)
>
> Hi Apache RocketMQ Community,
>
>
>
>
> The Project Management Committee (PMC) for Apache RocketMQ has invited
>
> Yang Zhang (apache id: zhangyang, github id:Git-Yang)
>
> to become committers, and we are pleased to announce that he has accepted.
>
>
>
>
> Congrats, guys :-)
>
>
>
>
> Best Wishes,
>
> RongtongJin
>

Re: In December，Apache APISIX Community want to online meetup with Apache RocketMQ

[heng du]

Hi, Yeliang & APISIX community,

I'm Henry, a PMC member of Apache RocketMQ.

Thanks for your invitation and I'm very honored to hold a Meetup with the
APISIX community.

I wonder if we could change the date of this Meetup to sometime later in
December? So how about December 26th? and please feel free to schedule
another time convenient for you.


Thanks,
Henry



yeliang wang  于2021年11月10日周三 下午1:52写道：

> Hi, community,
>
> My name is Yeliang Wang, and I am Apache APISIX Committer.
>
> i want to have the Apache APISIX Online Meetup on December 11th, and I hope
> to invite RocketMQ to participate.
>
> Participation content:
> 1、Two keynote, One topic for 45 minutes.
>
> Thanks,
> Yeliang Wang, Apache APISIX Committer
> Github: wang-yeliang
>

Re: [VOTE][RIP-26] Improve Batch Message Processing Throughput

[heng du]

+1

Erik  于2021年11月1日周一 上午11:38写道：

> Hi RocketMQ Community,
>
>
> This is the vote for the kickoff of RIP-26 Improve Batch Message
> Processing Throughput
>
>
> As discussed in the previous email, we launched a new RIP to improve batch
> message processing throughput. Now the shepherds @dongeforever are willing
> to support the RIP, so I think it is time to start an email thread to enter
> the voting process.
>
>
> The vote will be open for at least 72 hours or until a necessary number of
> votes are reached.
> Please vote accordingly:
>
>
> [ ] +1 approve
> [ ] +0 no opinion
> [ ] -1 disapprove with the reason
>
>
>
>
> Best Regards!
> Erik1288
>
>
>
>
> RIP-26 Improve Batch Message Processing Throughput
>
> https://docs.google.com/document/d/10hlfG6Jg36D8Kid6t8Zuf3g_63pb8yQZqwRqV2GZkEQ/edit?usp=sharing

Re: [ANNOUNCE] Release Apache RocketMQ 4.9.2

[heng du]

Thank you, tiger lee & Tongrong Jin, for managing this release!
Thanks Jason918, maixiaohai, Aaron-He, WJL, areyouok ,zhangjidi2016,
Git-Yang  and guyinyou and everyone who made this release happen.

Cheers,
Henry

tiger lee  于2021年10月26日周二 下午1:45写道：

> Hi all,
>
> The Apache RocketMQ team would like to announce the release of Apache
> RocketMQ 4.9.2.
>
> This release is to improve some features and issues for Apache RocketMQ,
>
> such as Support Multiple Directories Storage, Support metadata export and
> improve some performances and so on.
>
> More details regarding Apache RocketMQ can be found at:
> http://rocketmq.apache.org/
>
> The release artifacts can be downloaded here:
> https://dist.apache.org/repos/dist/release/rocketmq/4.9.2
>
> The release notes can be found here:
> https://rocketmq.apache.org/release_notes/release-notes-4.9.2
>
> Thanks,
> The Apache RocketMQ Team
>

Re: [ANNOUNCE] Release Apache RocketMQ 4.9.2

[heng du]

Thank you, tiger lee & Tongrong Jin, for managing this release!
Thanks Jason918, maixiaohai, Aaron-He, WJL, areyouok ,zhangjidi2016,
Git-Yang  and guyinyou and everyone who made this release happen.

Cheers,
Henry

tiger lee  于2021年10月26日周二 下午1:45写道：

> Hi all,
>
> The Apache RocketMQ team would like to announce the release of Apache
> RocketMQ 4.9.2.
>
> This release is to improve some features and issues for Apache RocketMQ,
>
> such as Support Multiple Directories Storage, Support metadata export and
> improve some performances and so on.
>
> More details regarding Apache RocketMQ can be found at:
> http://rocketmq.apache.org/
>
> The release artifacts can be downloaded here:
> https://dist.apache.org/repos/dist/release/rocketmq/4.9.2
>
> The release notes can be found here:
> https://rocketmq.apache.org/release_notes/release-notes-4.9.2
>
> Thanks,
> The Apache RocketMQ Team
>

Re: [RESTART][VOTE] Release Apache RocketMQ 4.9.2 RC3

[heng du]

+1

I checked:
[OK]  Source code artifacts have correct names matching the current release.
[OK]  Hash and Tag in GitHub repo are matching the current artifacts.
[OK]  The code can be built success in the source package.
[OK]  Start nameserver and broker according to the quick-start
[OK]  Run clusterList command to see if the version is correct
[OK]  The  staging repo in maven is OK
[OK]  All unit tests can pass.

panzhi  于2021年10月24日周日 下午10:16写道：

> +1
>
> I checked:
> [OK] Source code artifacts have correct names matching the current
> release.
> [OK] Hash and Tag in GitHub repo are matching the current artifacts.
> [OK] The code can be built success in the source package.
> [OK] Start nameserver and broker according to the quick-start
> [OK] Run cluster list command to see if the version is correct
> [OK] The staging repo in maven is OK
> [OK] All unit tests can pass.
>
>
>
>
>
> --原始邮件--
> 发件人:
>   "dev"
> <
> stylet...@apache.org;
> 发送时间:2021年10月24日(星期天) 下午5:40
> 收件人:"users" 抄送:"dev" 主题:Re: [RESTART][VOTE] Release Apache RocketMQ 4.9.2 RC3
>
>
>
> +1
>
> I checked:
> [OK] Source code artifacts have correct names matching the current
> release.
> [OK] Hash and Tag in GitHub repo are matching the current artifacts.
> [OK] The code can be built success in the source package.
> [OK] Start nameserver and broker according to the quick-start
> [OK] Run cluster list command to see if the version is correct
> [OK] The staging repo in maven is OK
> [OK] All unit tests can pass.
>
>
> Rongtong Jin 
>  +1
> 
>  I checked:
>  [OK] Source code artifacts have correct names matching the
> current
>  release.
>  [OK] Hash and Tag in GitHub repo is matching the current
> artifacts.
>  [OK] The code can be built success in the source package.
>  [OK] Start nameserver and broker according to the quick-start
>  [OK] Run clusterList command to see if the version is correct
>  [OK] The staging repo in maven is OK
>  [OK] All unit tests can pass.
> 
>  quot;Francis Leequot; lt;francism...@gmail.com
> gt;写道：
>   Hello RocketMQ Community,
>  
>   This is the vote for 4.9.2 of Apache RocketMQ.
>   This release is to improve some features and issues for apache
>   rocketmq,such as support for Multiple Directories Storage,
> improve
>   performances, fix some bugs and issues and so on.
>  
>   The artifacts:
>   https://dist.apache.org/repos/dist/dev/rocketmq/4.9.2-rc3/
>  ; 
>   The staging repo:
>  
> 
> https://repository.apache.org/content/repositories/orgapacherocketmq-1071
> 
> ;
> 
>   Git tag for the release:
>  
> https://github.com/apache/rocketmq/releases/tag/rocketmq-all-4.9.2
> 
> ;
> 
>   Hash for the release tag:
>   c840b208337b26c7529602b81d398c0a87a23888
>  
>   Release Notes:
>   https://rocketmq.apache.org/release_notes/release-notes-4.9.2/
>  ;
> 
>   The artifacts have been signed with Key :
>   F32A2D46, which can be found in the keys file:
>   https://dist.apache.org/repos/dist/dev/rocketmq/KEYS
>  
>  
>   The vote will be open for at least 72 hours or until the
> necessary number
>   of votes are reached.
>   Please vote accordingly:
>  
>   [ ] +1 approve
>   [ ] +0 no opinion
>   [ ] -1 disapprove with the reason
>  
>   Thanks
>   The Apache RocketMQ Team
> 

Re: [DISCUSS] RIP26-Improve Batch Message Processing Throughput [Google Docs Hosted]

[heng du]

Very pleased to see this proposal, which not only improves performance, but
also lays the foundation for rocketmq to enter the batch field.

Erik  于2021年10月15日周五 下午2:55写道：

> RIP26-Improve Batch Message Processing Throughput
> Status
> Current State: Draft
> Authors: Erik1288
> Shepherds: dongeforever
> Mailing List discussion: dev@rocketmq.apache.org;
> Pull Request: no
> Released: no
>
>
> Docs
>
> https://docs.google.com/document/d/10hlfG6Jg36D8Kid6t8Zuf3g_63pb8yQZqwRqV2GZkEQ/edit?usp=sharing
> The content was placed in Google Docs due to image display and formatting
> issues.
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>

Re: [VOTE]Release Apache RocketMQ Dashboard 1.0.0 RC1

[heng du]

+1，I checked'：
License and Notice are correct in source package.
All files have license headers in source package if necessary. No compiled
archives bundled in source archive.
Hash and Tag in GitHub repo are matching the current artifacts.
The code can be built success in the source package.
Source code artifacts have correct names matching the current release.

Jie Tang  于2021年9月25日周六 下午2:31写道：

> Hello RocketMQ Community,
>
> This is the vote for the 1.0.0 release of Apache Rocketmq-Dashboard.
>
> The artifacts:
> https://dist.apache.org/repos/dist/dev/rocketmq/rocketmq-dashboard/1.0.0-rc1/
>
> The staging repo:
> https://repository.apache.org/content/repositories/orgapacherocketmq-1061/
>
> Git tag for the release:
> https://github.com/apache/rocketmq-dashboard/releases/tag/rocketmq-dashboard-1.0.0
>
> Hash for the release tag: f6d4e18b899b0e7c492c6225f2036335d206a623
>
> Release Notes:
> https://rocketmq.apache.org/release_notes/release-notes-rocketmq-dashboard-1.0.0/
>
> The artifacts have been signed with Key : 
> FE85836A69AEBAAD67C599E67ED42D8104499F21,
> which can be found in the keys file:
>
> https://dist.apache.org/repos/dist/dev/rocketmq/KEYS
>
> Checklist for reference, Note that this is not an official policy but may
> help with checking releases.
>
> Fill in the following: [ ] Checksums and PGP signatures are valid for
> source package. [ ] Source code artifacts have correct names matching the
> current release. [ ] License and Notice are correct in source package. [
> ] All files have license headers in source package if necessary. [ ] No
> compiled archives bundled in source archive. [ ] Hash and Tag in GitHub
> repo are matching the current artifacts. [ ] The code can be built
> success in the source package.
>
> And any other checkpoint is welcomed and please feel free to reply to this
> email, we sincerely hope for your feedback. The vote will be open for at
> least 72 hours or until a necessary number of votes are reached.
>
> Please vote accordingly: [ ] +1 approve [ ] +0 no opinion [ ] -1
> disapprove with the reason
>
> Thanks, The Apache RocketMQ Team
>

Re: [DISCUSS] Support KV semantic storage

[heng du]

Glad to see everyone’s discussion，Er, the compact topic is also a way to
implement the KV semantic storage, but If the compact index is introduced,
In fact, different from messaging products, it cannot be used as a log
cleaner，and will only be used to reduce the cost of message replay, and if
we want to make the compact topic to be a way to clean up messages like
other messaging products, the changes to the storage layer will also be
very large.

dongeforever  于2021年9月24日周五 下午8:41写道：

> keep calm.
> Every RocketMQ contributor has the responsibility to maintain and develop
> the architecture.
> Integrating RocksDB has its pros and cons, so does the compaction(not
> compression) topic.
> It's better to continue the discussion if each could show the details
> without emotion.
> It is also ok to start a meeting about this proposal.
>
> In my opinion, KV feature is important for RocketMQ, the question is in
> what a way.
>
> vongosling  于2021年9月24日周五 下午3:58写道：
>
> > I just wonder if we could not open a new kV module, we really could not
> > solve the question you're mentioned? we could introduce a compression
> topic
> > for the last effective replay. Do we know how hard it is to maintain a
> > RocksDB, which my Facebook friends have talked to me a lot about,
> > their various kV production around RocksDB?
> >
> > Since we open-source RocketMQ, I've tried to help keep the architecture
> as
> > simple as possible, and I've warned you to learn to subtract while adding
> > things. While the code scale is still under control, I think the first
> > thing to really do is to design a good pluggable system that replaces the
> > existing simple SPI and API approach, but unfortunately, I haven't seen
> any
> > progress in that regard so far.
> >
> > Therefore, I think we should carefully examine our technical solutions.
> We
> > should not let the technical solutions just only for streams :-)
> >
> > heng du  于2021年9月24日周五 下午12:43写道：
> >
> > > Totally agree with this proposal. The KV semantic storage can not only
> > > provide better support for streaming and connect, especially the
> storage
> > of
> > > checkpoints but also can be used to better manage metadata in the
> future.
> > > At the same time, compared to the compact topic, this proposal can
> > > significantly reduce user replay costs and save failure recovery time,
> > and
> > > KV semantic storage can actually be regarded as another index similar
> to
> > > CQ, which can be loaded on demand. In addition, there seems to be an
> > > unvoted RIP-22 proposal, but please don’t care :)
> > >
> > >
> > > vongosling  于2021年9月23日周四 下午8:35写道：
> > >
> > > > Thanks for your clarify. I have been confused by RIP 22, It seems we
> > have
> > > > occupied 22, right[1]?
> > > >
> > > >
> > > > [1] https://github.com/apache/rocketmq/issues/2937
> > > >
> > > > Amber Liu  于2021年9月23日周四 下午3:29写道：
> > > >
> > > > > Sorry about the format problem, below is the correct one.
> > > > > RIP-22 Support KV semantic storageStatus
> > > > >
> > > > >- Current Status: Draft
> > > > >- Authors: ltamber <https://github.com/ltamber>
> > > > >
> > > > >
> > > > >- Shepherds: duhengforever 
> > > > >- Mailing List discussion: dev@rocketmq.apache.org
> > > > >
> > > > >
> > > > >- Pull Request: #PR_NUMBER
> > > > >- Released: 
> > > > >
> > > > > Background & Motivationwhat do we need to do
> > > > >
> > > > >- will we add a new module? *no*.
> > > > >- will we add new APIs? *yes*.
> > > > >
> > > > >
> > > > >- will we add new feature? *yes*.
> > > > >
> > > > > Why should we do that
> > > > >
> > > > >- Are there any problems of our current project?
> > > > >  Currently, we can't get/put key-value from/into rocketmq, so
> if
> > we
> > > > use
> > > > >connector <https://github.com/apache/rocketmq-externals>, like
> > > > >FileSource, BinlogSource, we can't persist current read
> > > position/dump
> > > > >position to rocketmq rather than an external meta store like
> > > > >zookeeper/mysql, this will bring more operator risk by introduce
> > > &

Re: [DISCUSS] Support KV semantic storage

[heng du]

Totally agree with this proposal. The KV semantic storage can not only
provide better support for streaming and connect, especially the storage of
checkpoints but also can be used to better manage metadata in the future.
At the same time, compared to the compact topic, this proposal can
significantly reduce user replay costs and save failure recovery time, and
KV semantic storage can actually be regarded as another index similar to
CQ, which can be loaded on demand. In addition, there seems to be an
unvoted RIP-22 proposal, but please don’t care :)


vongosling  于2021年9月23日周四 下午8:35写道：

> Thanks for your clarify. I have been confused by RIP 22, It seems we have
> occupied 22, right[1]?
>
>
> [1] https://github.com/apache/rocketmq/issues/2937
>
> Amber Liu  于2021年9月23日周四 下午3:29写道：
>
> > Sorry about the format problem, below is the correct one.
> > RIP-22 Support KV semantic storageStatus
> >
> >- Current Status: Draft
> >- Authors: ltamber 
> >
> >
> >- Shepherds: duhengforever 
> >- Mailing List discussion: dev@rocketmq.apache.org
> >
> >
> >- Pull Request: #PR_NUMBER
> >- Released: 
> >
> > Background & Motivationwhat do we need to do
> >
> >- will we add a new module? *no*.
> >- will we add new APIs? *yes*.
> >
> >
> >- will we add new feature? *yes*.
> >
> > Why should we do that
> >
> >- Are there any problems of our current project?
> >  Currently, we can't get/put key-value from/into rocketmq, so if we
> use
> >connector , like
> >FileSource, BinlogSource, we can't persist current read position/dump
> >position to rocketmq rather than an external meta store like
> >zookeeper/mysql, this will bring more operator risk by introduce
> another
> >component. this issue was also in streaming
> > scenarios when developer
> >want to persist meta info like checkpoint.
> >- What can we benefit proposed changes?
> >   rocketmq would not rely on external componet such as zookeeper/etcd
> >to support meta data storage.
> >
> > Goals
> >
> >- What problem is this proposal designed to solve?
> >   Design a distribution persistent key-value store,  application can
> >put key-value into broker, and then get the value after a while, in
> the
> >same time, it can also have the ability like compareAndSet, prefix get
> > and
> >so on.
> >- To what degree should we solve the problem?
> >   This RIP must guarantee below point:
> >   1. High availablity: if one broker in the broker group is down,
> >application can put/get key-value through other broker, the
> availablity
> > is
> >same with the message of rocketmq.
> >   2. High capacity: the amount of key-value may very large, so the
> >key-value can not store in memory,  we must store the key-value in
> disk
> >device.
> >
> > Non-Goals
> >
> >- What problem is this proposal NOT designed to solve?
> >   Nothing specific.
> >- Are there any limits of this proposal?
> >   Nothing specific.
> >
> > ChangesArchitecture
> >
> >
> >
> > We will introduce rocksdb  to
> persist
> > key-value data, to say it more accurately, we use rocksdb to compact the
> > value with the same key, we will not enable WAL in rocksdb to decrease
> > write amplification (most case), instead we can recover the rocksdb state
> > and consistency by redo rocketmq commitlog. so the put/get flow showed on
> > the above figure is:
> > put: the key-value message will put into commitlog first, and then
> through
> > the reputService redo commitlog, the key-value will put to rocksdb
> > asynchronous, until this reput finished broker will not response to
> client.
> > get: application will get key-value from rocksdb thought broker directly.
> > In addition, if we don't want introduce rocksdb
> >  and the meta data content will not
> > occupy too many memory, we can also use a key-value store base on memory
> > map, there will a periodic serialization and persistence thread to
> > guarantee data won't loss if broker restart or system abnormal shutdown,
> > and the memory state consistency will also guaranteed by redo rocketmq
> > commitlog.
> > Interface Design/Change
> >
> >- Method signature changes. *No*
> >- Method behavior changes. *No*
> >
> >
> >- CLI command changes. *No*
> >- Log format or content changes.
> >   the properties of the message will add two flag, kv_opType indicate
> >the request type is put key-value or get key-value, and key indicate
> the
> >request key both in put or get operation. In order to pass the key
> > through
> >the network in the request header, we will encode/decode the key(byte
> > array
> >format) use base64
> >
> > encoding 

Re: ​[ANNOUNCE]New Committers of Apache RocketMQ: Li Zhibo(apache id:osgooli)

[heng du]

Congrats !

Amber Liu  于2021年9月24日周五 上午11:34写道：

> Congrats ! well deserved!
>
> ShannonDing  于2021年9月24日周五 上午10:41写道：
>
> > Hi Apache RocketMQ Community,
> >
> >
> >
> >
> > The Project Management Committee (PMC) for Apache RocketMQ has invited
> >
> > Li Zhibo(apache id:osgooli),
> >
> > to become a committer, and we are pleased to announce that he has
> > accepted.
> >
> >
> >
> >
> > Congrats, guy :-)
> >
> >
> >
> >
> > Best Wishes,
> >
> > ShannonDing
>

Re: [VOTE]Release Apache RocketMQ 5.0.0-PREVIEW RC1

[heng du]

+1
[ok]  build the source, start nameserver and broker according to the
quick-start
[ok]  run clusterList command to see if the version is correct
[ok]  extract the zip and check if the source version is correct

Amber Liu  于2021年9月6日周一 下午8:36写道：

> +1 (non-binding)
>
> checked:
> [ok]  check LICENSE, should be Apache V2
> [ok]  check NOTICE, should have a notice for third-party dependency if
> necessary
> [ok]  extract the zip and check if the source version is correct
> [ok]  verify the asc(PGP sign),SHA512
> [ok]  build the source, start nameserver and broker according to the
> quick-start
> [ok]  run clusterList command to see if the version is correct
>
> 周波  于2021年9月6日周一 下午1:02写道：
>
> > Hello RocketMQ Community,
> >
> > This is the vote for 5.0.0-PREVIEW of Apache RocketMQ.
> >
> >
> > The artifacts:
> > https://dist.apache.org/repos/dist/dev/rocketmq/5.0.0-PREVIEW-rc1/
> >
> >
> > The staging repo:
> >
> https://repository.apache.org/content/repositories/orgapacherocketmq-1059
> >
> >
> > Git tag for the release:
> >
> https://github.com/apache/rocketmq/releases/tag/rocketmq-all-5.0.0-PREVIEW
> >
> >
> > Hash for the release tag:
> > d969670ea5dc2b9acde99266bbf7e16691ac787f
> >
> >
> > Release Notes:
> > https://rocketmq.apache.org/release_notes/release-notes-5.0.0-PREVIEW/
> >
> >
> > The artifacts have been signed with Key :
> > DA38AD870652D9961F82EDC4E2DED90716D986F7, which can be found in the keys
> > file:
> >
> >
> > https://dist.apache.org/repos/dist/dev/rocketmq/KEYS
> >
> >
> > Checklist for reference,
> > Note that this is not an official policy but may help with checking
> > releases.
> >
> > Fill in the following:
> > [ ]  check LICENSE, should be Apache V2
> > [ ]  check NOTICE, should have a notice for third-party dependency if
> > necessary
> > [ ]  extract the zip and check if the source version is correct
> > [ ]  verify the asc(PGP sign),SHA512
> > [ ]  build the source, start nameserver and broker according to the
> > quick-start
> > [ ]  run clusterList command to see if the version is correct
> >
> >
> > And any other checkpoint is welcomed and please feel free to reply to
> this
> > email, we sincerely hope for your feedback.
> > The vote will be open for at least 72 hours or until a necessary number
> of
> > votes are reached.
> >
> >
> > Please vote accordingly:
> >
> >
> > [ ] +1 approve
> > [ ] +0 no opinion
> > [ ] -1 disapprove with the reason
> >
> >
> > Thanks,
> >
> > The Apache RocketMQ Team
> >
>

Re: [VOTE]Release Apache RocketMQ Spring 2.2.1 RC1

[heng du]

+1

checked：

[[ok] Source code artifacts have correct names matching the current release.
[ok] License and Notice are correct in the source package.
[ok] All files have license headers in the source package if necessary.
[ok] No compiled archives bundled in the source archive.
[ok] Hash and Tag in GitHub repo are matching the current artifacts.
[ok] The code can be built success in the source package.

jinrongtong  于2021年8月31日周二 下午6:57写道：

> Hello RocketMQ Community,
>
>
>
> This is the vote for the 2.2.1 release of Apache RocketMQ-Spring.
>
>
> The artifacts:
> https://dist.apache.org/repos/dist/dev/rocketmq/rocketmq-spring/2.2.1-rc1/
>
>
> The staging repo:
> https://repository.apache.org/content/repositories/orgapacherocketmq-1060
>
>
> Git tag for the release:
>
> https://github.com/apache/rocketmq-spring/releases/tag/rocketmq-spring-all-2.2.1
>
>
> Hash for the release tag:
> 7fbcc85e1161154a60a94e1b0e654c19443bf160
>
>
> Release Notes:
>
> http://rocketmq.apache.org/release_notes/release-notes-rocketmq-spring-2.2.1/
>
>
> The artifacts have been signed with Key :
> EC9F268B4C20590138B11FE701420E4292296EAE, which can be found in the keys
> file:
>
>
> https://dist.apache.org/repos/dist/dev/rocketmq/KEYS
>
>
> Checklist for reference,
> Note that this is not an official policy but may help with checking
> releases.
>
>
> Fill in the following:
> [ ]  Checksums and PGP signatures are valid for source package.
> [ ]  Source code artifacts have correct names matching the current release.
> [ ]  License and Notice are correct in source package.
> [ ]  All files have license headers in source package if necessary.
> [ ]  No compiled archives bundled in source archive.
> [ ]  Hash and Tag in GitHub repo are matching the current artifacts.
> [ ]  The code can be built success in the source package.
>
>
> And any other checkpoint is welcomed and please feel free to reply to this
> email, we sincerely hope for your feedback.
> The vote will be open for at least 72 hours or until a necessary number of
> votes are reached.
>
>
> Please vote accordingly:
> [ ] +1 approve
> [ ] +0 no opinion
> [ ] -1 disapprove with the reason
>
>
>
>
> Thanks,
> The Apache RocketMQ Team

[ANNOUNCE] New committer involved, welcome Jidi Zhang

[heng du]

Hi,

The Project Management Committee (PMC) for Apache RocketMQ has invited
Jidi Zhang to become a committer and we are pleased to announce that he has
accepted.

Being a committer enables easier contribution to the project since there is
no need to go via the patch submission process. This should enable better
productivity.


Yours,
Apache RocketMQ PMC

[ANNOUNCE] New committer involved, welcome Xiaofeng Jiang

[heng du]

Hi,

The Project Management Committee (PMC) for Apache RocketMQ has invited
Xiaofeng Jiang to become a committer and we are pleased
to announce that he has accepted.

Being a committer enables easier contribution to the project since there is
no need to go via the patch submission process. This should enable better
productivity.


Yours,
Apache RocketMQ PMC

Re: [VOTE]:Release Apache RocketMQ 4.9.1 RC1.

[heng du]

+1

I checked:
[OK]  Hash and Tag in GitHub repo are matching the current artifacts.
[OK]  The code can be built success in the source package.
[OK]  Run clusterList command to see if the version is correct
[OK] Quickstart works well


倪泽  于2021年8月18日周三 下午4:43写道：

> +1
>
> My check list is as fellow:
>
> artifacts package is the same as current release version.
> source package can build success
> nameserver and broker can start up
> clusterlist command can success and version is correct.
> use tools to produce and consume message success.
>
>
>
>
> 周波  于2021年8月18日周三 下午4:26写道：
>
> > +1
> >
> > I checked:
> > [OK]  Source code artifacts have correct names matching the current
> > release.
> > [OK]  Hash and Tag in GitHub repo is matching the current artifacts.
> > [OK]  The code can be built success in the source package.
> > [OK]  Run clusterList command to see if the version is correct
> > [OK]  Build the source, start nameserver and broker according to the
> > quick-start
> > [OK]  All unit tests of the current version pass
> >
> > caigy  于2021年8月18日周三 下午4:18写道：
> >
> > > I vote +1 (non-binding)
> > >
> > >
> > >
> > >
> > > I checked the following:
> > >
> > > - Licence by Apache RAT
> > >
> > > - Hashes of binary and source files are correct
> > >
> > > - Signatures of binary and source files are correct
> > >
> > > - Source code can be built successfully and all unit tests are passed
> > > locally
> > > - Nameserver and Broker can be run successfully and mqadmin clusterList
> > > command responds correct cluster message
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> >
>

Re: ASF Board Report for RocketMQ - Repeated Reminder for August 2021

[heng du]

Hi，AFAIK,

Sorry, the latest board report was submitted late. In fact, PMC members
have regularly summarized board reports and discussed them on the mailing
list，as shown in the figure below:
[image: image.png]
[image: image.png]

But I’m sorry that these summaries were not sent to the board mailing list
after the discussion. This is an oversight of PMC’s work. As one of the
PMCs who have been active in the community for a long time, I am
responsible for this, and I will help to promote and improve the board
report process in the RocketMQ community.

In fact, after RocketMQ entered the apache foundation, the diversity and
activity of the community have been greatly improved. A large number of new
features and new projects have been created. These are all initiated by
PMCs, especially in Recently, it can be seen from our community data that
the community is moving towards a more active state:
dev@rocketmq.apache.org had a 95% increase in traffic in the past quarter
( emails compared to 1703)
us...@rocketmq.apache.org had a 34% decrease in traffic in the past quarter
(6 emails compared to 9)
203 commits in the past quarter (75% increase)
73 code contributors in the past quarter (62% increase)
235 PRs opened on GitHub, past quarter (60% increase)
267 PRs closed on GitHub, past quarter (164% increase)
276 issues opened on GitHub, past quarter (33% increase)
237 issues closed on GitHub, past quarter (54% increase)

In the coming time, I and other PMCs will actively participate to help more
developers become committers and PMCs, and make the RocketMQ community more
active.

Thanks
Henry

vongosling  于2021年8月11日周三 上午9:51写道：

> Hi,
>
> I'm sorry we filed a little late last time. AFAIK, we're far from that
> Attic status, although there aren't many active committers or PMC in
> mailing lists lately. Recently, I am calling on more PMCs to fulfill the
> responsibilities that when we joined. Perhaps because of personal work like
> me, they have been slightly neglecting the community in these years.
> Fortunately, I've seen more new projects being created lately, and I'm
> actively calling on some PMC to focus on the community and absorb more
> committers. To be honest, I personally thought about starting the
> community's retirement process and getting more committers and PMCs, We've
> never been short of active contributors, we need to keep our eyes on them.
> As for the chair role, the majority of submissions in recent years have
> been made jointly by the community PMC. That's how we've been, and that's
> how we've been working from the beginning. I personally don't see anything
> wrong with it, and if rotation is needed, it's not a big problem.
>
>
> This year is our fifth year, RocketMQ has seen a huge increase in
> diversity and active contributors, but the problems that come with it are
> obvious. I will be returning to the community in the near future. I would
> like to help and mentor more committers and PMCs. I hope that PMCs who have
> similar ideas could also express their views.
>
>
> Sander Striker  于2021年8月11日周三 上午5:17写道：
>
>> Dear RocketMQ community,
>>
>> In the Apache governance model, the ASF board delegates responsibility for
>> managing projects to PMCs. This allows projects to govern themselves, in
>> terms
>> of their own development goals, guidelines, and volunteer spirit, within
>> the
>> scope of our purpose as an open source foundation. The state allows us to
>> supply an umbrella of corporate protection to our projects and
>> volunteers, but
>> only to the extent that we retain active and effective oversight of each
>> project's operation on behalf of the public's interest.
>>
>> To enable the board to provide oversight across the foundation, each PMC
>> is
>> tasked with providing the board a quarterly report on the health of their
>> project. This allows us to hear your heartbeat, to see the project through
>> your eyes, and to inform the public through our meeting minutes.
>>
>> The board has noticed that the reports for RocketMQ have been missed
>> for a number of months. This makes us sad because we have lost that
>> ability
>> to communicate with you, to see what may be preventing your good health,
>> and to ensure that we are providing the services that you need to continue
>> as an Apache project.
>>
>> The reports to the board are normally written by the PMC chair but all PMC
>> members have an individual responsibility to ensure that a report is
>> submitted. If the PMC chair is not available then any PMC member can
>> submit
>> the report. If you need help with this process, please reach out to
>> bo...@apache.org
>>
>> Please ensure that a report for RocketMQ is submitted to the board
>> for the next meeting.
>>
>> If the PMC chair is not going to be available for an extended period of
>> time,
>> it may make sense to rotate the PMC chair. Rotating the PMC chair does not
>> mean the current chair has failed. People's situations and interests
>> change;
>> rotation is good 

ASF Board Report for RocketMQ - August 2021

[heng du]

Dear board，

Here is the Apache RocketMQ Board Report - August 2021, and thanks for your
review，

## Description:
The mission of Apache RocketMQ is the creation and maintenance of software
related to a fast, low latency, reliable, scalable, distributed, easy to use
message-oriented middleware, especially for processing large amounts of
streaming data

## Issues:
There are no issues requiring board attention at this time.

## Membership Data:
Apache RocketMQ was founded 2017-09-20 (4 years ago)
There are currently 37 committers and 14 PMC members in this project.
The Committer-to-PMC ratio is roughly 5:2.

Community changes, past quarter:
- No new PMC members. The last addition was Rongtong Jin on 2020-03-30.
- Zhimin Li was added as a committer on 2021-07-29
- Bo Zhou was added as a committer on 2021-06-08

## Project Activity:
ROCKETMQ-4.9.0 was released on 2021-06-15.
ROCKETMQ-CLIENT-GO-2.1.0 was released on 2021-03-23.
ROCKETMQ-SPRING-2.2.0 was released on 2021-01-22.


## Community Health:
The RocketMQ community has remained very healthy in the latest quarter,
with more and more developers participating and being more active, which
not only increased RocketMQ's own performance by 15% but also started
discussions, development of RocketMQ-Streams, Compared with last quarter：

dev@rocketmq.apache.org had a 95% increase in traffic in the past quarter
( emails compared to 1703)
us...@rocketmq.apache.org had a 34% decrease in traffic in the past quarter
(6 emails compared to 9)
203 commits in the past quarter (75% increase)
73 code contributors in the past quarter (62% increase)
235 PRs opened on GitHub, past quarter (60% increase)
267 PRs closed on GitHub, past quarter (164% increase)
276 issues opened on GitHub, past quarter (33% increase)
237 issues closed on GitHub, past quarter (54% increase)

Sander Striker  于2021年8月11日周三 上午5:17写道：

> Dear RocketMQ community,
>
> In the Apache governance model, the ASF board delegates responsibility for
> managing projects to PMCs. This allows projects to govern themselves, in
> terms
> of their own development goals, guidelines, and volunteer spirit, within
> the
> scope of our purpose as an open source foundation. The state allows us to
> supply an umbrella of corporate protection to our projects and volunteers,
> but
> only to the extent that we retain active and effective oversight of each
> project's operation on behalf of the public's interest.
>
> To enable the board to provide oversight across the foundation, each PMC is
> tasked with providing the board a quarterly report on the health of their
> project. This allows us to hear your heartbeat, to see the project through
> your eyes, and to inform the public through our meeting minutes.
>
> The board has noticed that the reports for RocketMQ have been missed
> for a number of months. This makes us sad because we have lost that ability
> to communicate with you, to see what may be preventing your good health,
> and to ensure that we are providing the services that you need to continue
> as an Apache project.
>
> The reports to the board are normally written by the PMC chair but all PMC
> members have an individual responsibility to ensure that a report is
> submitted. If the PMC chair is not available then any PMC member can submit
> the report. If you need help with this process, please reach out to
> bo...@apache.org
>
> Please ensure that a report for RocketMQ is submitted to the board
> for the next meeting.
>
> If the PMC chair is not going to be available for an extended period of
> time,
> it may make sense to rotate the PMC chair. Rotating the PMC chair does not
> mean the current chair has failed. People's situations and interests
> change;
> rotation is good as it allows more people to become familiar with that
> role.
> Again, if assistance is required with this process, please feel free to
> reach out to bo...@apache.org
>
> As projects mature, they will naturally reach a point where activity
> reduces
> to a level that the project is no longer sustainable. At Apache, projects
> reach this stage when there are no longer 3 active PMC members providing
> oversight. Projects that reach this stage are placed in our Attic, where
> they continue to be accessible to the public but are not portrayed as
> having
> an active community for maintenance.
>
> http://attic.apache.org/
>
> If RocketMQ has reached this point, please reach out to the Attic project
> to arrange transfer. On the other hand, if your project is mostly dormant
> but
> still has at least three active PMC members, it can remain in that state
> for
> as long as needed. If your project is in such a state, please mention that
> in
> your report and verify the PMC's state at regular intervals.
>
> Finally, if you have any questions, please feel free to reach out to
> bo...@apache.org.
>
> Thanks,
> The ASF Board
>

【DISCUSS】ASF Board Report for RocketMQ - August 2021

[heng du]

Hi, all,

Here is the draft of Apache RocketMQ Board Report - August 2021,

please have a review on it asap, and reply to the email if you want to add
something in it.

if no other sounds from our members in 72 hours, I would like to report it
to the board.

## Description:
The mission of Apache RocketMQ is the creation and maintenance of software
related to a fast, low latency, reliable, scalable, distributed, easy to use
message-oriented middleware, especially for processing large amounts of
streaming data

## Issues:
There are no issues requiring board attention at this time.

## Membership Data:
Apache RocketMQ was founded 2017-09-20 (4 years ago)
There are currently 37 committers and 14 PMC members in this project.
The Committer-to-PMC ratio is roughly 5:2.

Community changes, past quarter:
- No new PMC members. The last addition was Rongtong Jin on 2020-03-30.
- Zhimin Li was added as a committer on 2021-07-29
- Bo Zhou was added as a committer on 2021-06-08

## Project Activity:
ROCKETMQ-4.9.0 was released on 2021-06-15.
ROCKETMQ-CLIENT-GO-2.1.0 was released on 2021-03-23.
ROCKETMQ-SPRING-2.2.0 was released on 2021-01-22.


## Community Health:
The RocketMQ community has remained very healthy in the latest quarter,
with more and more developers participating and being more active, which
not only increased RocketMQ's own performance by 15% but also started
discussions, development of RocketMQ-Streams, Compared with last quarter：

dev@rocketmq.apache.org had a 95% increase in traffic in the past quarter
( emails compared to 1703)
us...@rocketmq.apache.org had a 34% decrease in traffic in the past quarter
(6 emails compared to 9)
203 commits in the past quarter (75% increase)
73 code contributors in the past quarter (62% increase)
235 PRs opened on GitHub, past quarter (60% increase)
267 PRs closed on GitHub, past quarter (164% increase)
276 issues opened on GitHub, past quarter (33% increase)
237 issues closed on GitHub, past quarter (54% increase)


Sander Striker  于2021年8月11日周三 上午5:17写道：

> Dear RocketMQ community,
>
> In the Apache governance model, the ASF board delegates responsibility for
> managing projects to PMCs. This allows projects to govern themselves, in
> terms
> of their own development goals, guidelines, and volunteer spirit, within
> the
> scope of our purpose as an open source foundation. The state allows us to
> supply an umbrella of corporate protection to our projects and volunteers,
> but
> only to the extent that we retain active and effective oversight of each
> project's operation on behalf of the public's interest.
>
> To enable the board to provide oversight across the foundation, each PMC is
> tasked with providing the board a quarterly report on the health of their
> project. This allows us to hear your heartbeat, to see the project through
> your eyes, and to inform the public through our meeting minutes.
>
> The board has noticed that the reports for RocketMQ have been missed
> for a number of months. This makes us sad because we have lost that ability
> to communicate with you, to see what may be preventing your good health,
> and to ensure that we are providing the services that you need to continue
> as an Apache project.
>
> The reports to the board are normally written by the PMC chair but all PMC
> members have an individual responsibility to ensure that a report is
> submitted. If the PMC chair is not available then any PMC member can submit
> the report. If you need help with this process, please reach out to
> bo...@apache.org
>
> Please ensure that a report for RocketMQ is submitted to the board
> for the next meeting.
>
> If the PMC chair is not going to be available for an extended period of
> time,
> it may make sense to rotate the PMC chair. Rotating the PMC chair does not
> mean the current chair has failed. People's situations and interests
> change;
> rotation is good as it allows more people to become familiar with that
> role.
> Again, if assistance is required with this process, please feel free to
> reach out to bo...@apache.org
>
> As projects mature, they will naturally reach a point where activity
> reduces
> to a level that the project is no longer sustainable. At Apache, projects
> reach this stage when there are no longer 3 active PMC members providing
> oversight. Projects that reach this stage are placed in our Attic, where
> they continue to be accessible to the public but are not portrayed as
> having
> an active community for maintenance.
>
> http://attic.apache.org/
>
> If RocketMQ has reached this point, please reach out to the Attic project
> to arrange transfer. On the other hand, if your project is mostly dormant
> but
> still has at least three active PMC members, it can remain in that state
> for
> as long as needed. If your project is in such a state, please mention that
> in
> your report and verify the PMC's state at regular intervals.
>
> Finally, if you have any questions, please feel free to reach out to
> 

[DISCUSS]ASF Board Report for RocketMQ

[heng du]

## Description:
The mission of Apache RocketMQ is the creation and maintenance of software
related to a fast, low latency, reliable, scalable, distributed, easy to
use
message-oriented middleware, especially for processing large amounts of
streaming data

## Issues:
There are no issues requiring board attention at this time.

## Membership Data:
Apache RocketMQ was founded 2017-09-20 (4 years ago)
There are currently 37 committers and 14 PMC members in this project.
The Committer-to-PMC ratio is roughly 5:2.

Community changes, past quarter:
- No new PMC members. The last addition was Rongtong Jin on 2020-03-30.
- Zhimin Li was added as a committer on 2021-07-29
- Bo Zhou was added as a committer on 2021-06-08

## Project Activity:
ROCKETMQ-4.9.0 was released on 2021-06-15.
ROCKETMQ-CLIENT-GO-2.1.0 was released on 2021-03-23.
ROCKETMQ-SPRING-2.2.0 was released on 2021-01-22.


## Community Health:
The RocketMQ community has remained very healthy in the latest quarter,
with more and more developers participating and being more active, which
not only increased RocketMQ's own performance by 15% but also started
discussions, development of RocketMQ-Streams, Compared with last quarter：

dev@rocketmq.apache.org had a 95% increase in traffic in the past quarter
( emails compared to 1703)
us...@rocketmq.apache.org had a 34% decrease in traffic in the past quarter
(6 emails compared to 9)
203 commits in the past quarter (75% increase)
73 code contributors in the past quarter (62% increase)
235 PRs opened on GitHub, past quarter (60% increase)
267 PRs closed on GitHub, past quarter (164% increase)
276 issues opened on GitHub, past quarter (33% increase)
237 issues closed on GitHub, past quarter (54% increase)



Sander Striker  于2021年8月11日周三 上午5:17写道：

> Dear RocketMQ community,
>
> In the Apache governance model, the ASF board delegates responsibility for
> managing projects to PMCs. This allows projects to govern themselves, in
> terms
> of their own development goals, guidelines, and volunteer spirit, within
> the
> scope of our purpose as an open source foundation. The state allows us to
> supply an umbrella of corporate protection to our projects and volunteers,
> but
> only to the extent that we retain active and effective oversight of each
> project's operation on behalf of the public's interest.
>
> To enable the board to provide oversight across the foundation, each PMC is
> tasked with providing the board a quarterly report on the health of their
> project. This allows us to hear your heartbeat, to see the project through
> your eyes, and to inform the public through our meeting minutes.
>
> The board has noticed that the reports for RocketMQ have been missed
> for a number of months. This makes us sad because we have lost that ability
> to communicate with you, to see what may be preventing your good health,
> and to ensure that we are providing the services that you need to continue
> as an Apache project.
>
> The reports to the board are normally written by the PMC chair but all PMC
> members have an individual responsibility to ensure that a report is
> submitted. If the PMC chair is not available then any PMC member can submit
> the report. If you need help with this process, please reach out to
> bo...@apache.org
>
> Please ensure that a report for RocketMQ is submitted to the board
> for the next meeting.
>
> If the PMC chair is not going to be available for an extended period of
> time,
> it may make sense to rotate the PMC chair. Rotating the PMC chair does not
> mean the current chair has failed. People's situations and interests
> change;
> rotation is good as it allows more people to become familiar with that
> role.
> Again, if assistance is required with this process, please feel free to
> reach out to bo...@apache.org
>
> As projects mature, they will naturally reach a point where activity
> reduces
> to a level that the project is no longer sustainable. At Apache, projects
> reach this stage when there are no longer 3 active PMC members providing
> oversight. Projects that reach this stage are placed in our Attic, where
> they continue to be accessible to the public but are not portrayed as
> having
> an active community for maintenance.
>
> http://attic.apache.org/
>
> If RocketMQ has reached this point, please reach out to the Attic project
> to arrange transfer. On the other hand, if your project is mostly dormant
> but
> still has at least three active PMC members, it can remain in that state
> for
> as long as needed. If your project is in such a state, please mention that
> in
> your report and verify the PMC's state at regular intervals.
>
> Finally, if you have any questions, please feel free to reach out to
> bo...@apache.org.
>
> Thanks,
> The ASF Board
>

[VOTE] RIP23: Support gRPC protocol

[heng du]

Hi RocketMQ Community,

This is the vote for the kickoff of RIP-23 RocketMQ gRPC protocol support.

On one hand RocketMQ. remoting module is too complicated to maintain, gRPC
makes it easier to establish a robust communication layer, the current
remoting module would be simplified radically.
On the other hand, gRPC has been the de-facto standard in CloudNative,
service mesh would be easily applied if gRPC is enabled.

So in this RIP, we want to support gRPC's protocol, simplify the current
communication layer of RocketMQ, make it easier to adapt to other
languages, which is not limited to CPP/GO/C#/GO。

The vote will be open for at least 72 hours or until a necessary number
of votes are reached.

Please vote accordingly:

[ ] +1 approve
[ ] +0 no opinion
[ ] -1 disapprove with the reason


i yangkun  于2021年6月8日周二 下午8:28写道：

> Background & Motivation
> What do we need to do
>
>
>   *   Will we add a new module?
> maybe.
>   *   Will we add new APIs?
> Yes.
>
>   *   Will we add new feature?
> Yes.
>
>
> Why should we do that
>
>
>   *   Are there any problems of our current project?
>
> a. Remoting module is too complicated to maintain, gRPC makes it easier to
> establish a robust communication layer, the current remoting module would
> be simplified radically.
>
> b. gRPC has been the de-facto standard in CloudNative, service mesh would
> be easily applied if gRPC is enabled.
>
> c. The private protocol of RocketMQ depends on the FastJson, it is
> difficult to adapt for other language.
>
> On the other side, since the pop consumer has been merged, we could
> implement new SDK based on gRPC and pop, which is easier to develop and
> maintain.
>
> Chinese Version:
>
> a. Remoting 模块对于长期的维护而言过于复杂了，我们可以使用 gRPC 更轻松地建立起一个健壮的通信层，这会使得现有的 remoting
> 模块从根本上得到简化。
>
> b. gRPC 目前已经是云原生时代的事实标准，使用 gRPC 可以使得我们天然获取一些云原生的能力，比如 Service Mesh。
>
> c. 目前 RocketMQ 的私有协议强烈依赖 FastJson，多语言的适配将会变得困难。
>
>
> 从另外一个角度来说，鉴于 pop 消费者已经被合并，我们可以基于 gRPC 和 pop 实现新的 SDK，新的 SDK 将会更加易于开发和维护。
>
> Goals
>
>
>   *   What problem is this proposal designed to solve?
>
> Support gRPC's protocol, simplify current communication layer oof
> RocketMQ, make it easier to adapt for other language, which is not limited
> to CPP/GO/C#/GO。
>
> Chinese Version:
>
> 支持 gRPC 协议，简化 RocketMQ 现有的通信层，复用 gRPC 的能力，简化多语言适配成本，不限于 CPP/GO/C#/GO。
>
>   *   To what degree should we solve the problem?
> This RIP must guarantee below point:
>
>   1.  Compatibility: Both of gRPC and RemotingCommand should be supported.
>   2.  High performance: This implementation does not affects latency and
> throughput.
>
>
> Chinese Version:
>
> 新方案需要保证两点：
>
>   1.  兼容性：同时支持 gRPC 和 RemotingCommand 协议，不影响现有功能。
>   2.  高性能：基于 gRPC 的实现不影响整理的延时和吞吐量。
>
>
> Non-Goals
>
>
>   *   What problem is this proposal NOT designed to solve?
> Nothing specific.
>   *   Are there any limits of this proposal?
> Nothing specific.
>
>
> Changes
> Architecture
>
>
> Current broker processor and client.
>
> [
> https://intranetproxy.alipay.com/skylark/lark/0/2021/png/200096/1623142547507-128b85f5-98f4-4568-85f8-28ef32982b7c.png
> ]
>
> Proposed gRPC processor and client.
>
> [
> https://intranetproxy.alipay.com/skylark/lark/0/2021/png/200096/1623142552491-a7f58ac0-cd7d-4ddd-936e-fb296b667196.png
> ]
>
> Broker would provide a protocol negotiate procedure to distinguish
> RemotingCommand from gRPC protocol. two kinds or processor in broker would
> re-use the same port to serve for RPC from different SDK.
>
>
> Chinese Version:
>
> broker 本身提供协议协商机制用于区分 RemotingCommnad 和 gRPC 协议，broker 针对 gRPC 和
> RemotingCommand 提供不同的 processor 为各自的 SDK 服务。
>
> Interface Design/Change
>
>
>   *   Method signature changes
> Nothing specific.
>   *   Method behavior changes
> Nothing specific.
>
>   *   CLI command changes
> Nothing specific.
>   *   Log format or content changes
> Nothing specific.
>
>
> Compatibility, Deprecation, and Migration Plan
>
>
>   *   Are backward and forward compatibility taken into consideration?
>
> Broker support processor of RemotingCommand and gRPC simultaneously, so
> there are one compatibility situations:
>
> If user migrates from original SDK to gRPC SDK in push mode, the
> re-balance policy should make sure that it would not cause repeated
> consumption for a lot of messages.
>
>   *   Are there deprecated APIs?
> Nothing specific.
>   *   How do we do migration?
> Nothing specific.
>
>
> Implementation Outline
>
>
> We will implement the proposed changes by 4 phases.
>
>
> Phase 1
>
>   1.  Provides gRPC protocol definition(IDL)
>
> Phase 2
>
>   1.  Implement gRPC processor of broker.
>   2.  Implement protocol negotiation of two kinds of protocol(gRPC and
> RemotingCommand)
>
> Phase 3
>
>   1.  Implement new JAVA and CPP native SDK based on gRPC
>
> Phase 4
>
>   1.  Implement native SDK base on gRPC for other language.
>
>
> Rejected Alternatives
>
>
> How does alternatives solve the issue you proposed?
>
>
> Thrift? not so much impact as gRPC in community.
>
>
> Pros and Cons of 

Re: [External Mail]Re: [VOTE] Release Apache RocketMQ 4.9.0 RC1.

[heng du]

+1

I checked:
[OK]  Source code artifacts have correct names matching the current release.
[OK]  Hash and Tag in GitHub repo are matching the current artifacts.
[OK]  The code can be built success in the source package.
[OK]  Start nameserver and broker according to the quick-start
[OK]  Run clusterList command to see if the version is correct
[OK] Sending and consuming messages in quick start

[image: image.png]



Xu16 Zhang 张旭  于2021年6月13日周日 下午10:31写道：

> +1
>
> I checked the release note，and found a duplicate issue link [ISSUE-2328]
>
>
>
> 
> 张旭
> 人工智能与云平台-云技术-计算平台组
> 电话: 15011056041
>
> 
> 发件人: Rongtong Jin 
> 发送时间: 2021年6月13日 17:31
> 收件人: dev@rocketmq.apache.org
> 主题: [External Mail]Re: [VOTE] Release Apache RocketMQ 4.9.0 RC1.
>
> *外部邮件，谨慎处理 | This message originated from outside of XIAOMI. Please treat
> this email with caution*
>
>
> +1
>
> I checked:
> [OK]  Source code artifacts have correct names matching the current
> release.
> [OK]  Hash and Tag in GitHub repo is matching the current artifacts.
> [OK]  The code can be built success in the source package.
> [OK]  Start nameserver and broker according to the quick-start
> [OK]  Run clusterList command to see if the version is correct
>
> 胡 宗棠 zongtan...@hotmail.com写道：
> > Hello RocketMQ Community,
> >
> >
> > This is the vote for 4.9.0 of Apache RocketMQ.
> >
> >
> > This release is to improve some features for apache rocketmq,such as
> >
> > supporting producer and cunsumer opentracing, lite pull consumer
> messaging trace, enhancing some stability in unit test cases,
> >
> > enhancing some parameter validation in the rocketmq acl module, adding
> some new mqadmin command and so on.
> >
> >
> >
> > The artifacts:
> >
> > https://dist.apache.org/repos/dist/dev/rocketmq/4.9.0-rc1/
> >
> >
> > The staging repo:
> >
> >
> https://repository.apache.org/content/repositories/orgapacherocketmq-1053/
> >
> >
> > Git tag for the release:
> >
> > https://github.com/apache/rocketmq/releases/tag/rocketmq-all-4.9.0
> >
> >
> > Hash for the release tag:
> >
> > 5203d52f1bab431ada236ba279c80e62778f8a15
> >
> >
> > Release Notes:
> >
> > https://rocketmq.apache.org/release_notes/release-notes-4.9.0/
> >
> >
> > The artifacts have been signed with Key :
> >
> > 5C7C4040979F32543B624C631DA2409169DAF54B, which can be found in the keys
> >
> > file:
> >
> > https://dist.apache.org/repos/dist/dev/rocketmq/KEYS
> >
> >
> > The vote will be open for at least 72 hours or until necessary number of
> >
> > votes are reached.
> >
> >
> > Please vote accordingly:
> >
> >
> > [ ] +1 approve
> >
> > [ ] +0 no opinion
> >
> > [ ] -1 disapprove with the reason
> >
> >
> > Thanks,
> >
> > The Apache RocketMQ Team
> >
> #/**本邮件及其附件含有小米公司的保密信息，仅限于发送给上面地址中列出的个人或群组。禁止任何其他人以任何形式使用（包括但不限于全部或部分地泄露、复制、或散发）本邮件中的信息。如果您错收了本邮件，请您立即电话或邮件通知发件人并删除本邮件！
> This e-mail and its attachments contain confidential information from
> XIAOMI, which is intended only for the person or entity whose address is
> listed above. Any use of the information contained herein in any way
> (including, but not limited to, total or partial disclosure, reproduction,
> or dissemination) by persons other than the intended recipient(s) is
> prohibited. If you receive this e-mail in error, please notify the sender
> by phone or email immediately and delete it!**/#
>

[RESULT][VOTE] RIP-21 RocketMQ Logical Queue

[heng du]

Hello RocketMQ Community,

This is the vote result for the kickoff of RIP-21 Apache RocketMQ logic
queue support, and it has been passed with [3] binding +1s, [3] non-binding:

*Binding votes +1s:*

heng du (duhengforever)

dongeforever(dongeforever)

Rongtongjin(Jinrongtong)


*Non-binding votes +1s:*

zhiboli
xu16 Zhang
炼龙




This RIP will be accepted and its status will be updated to RocketMQ  Wiki
soon.

Thanks,
The Apache RocketMQ Team

heng du  于2021年5月29日周六 上午9:55写道：

> Hi RocketMQ Community,
>
> This is the vote for the kickoff of RIP-21 RocketMQ logic queue.
>
> In order to better meet the needs of stream computing and scaling, the
> concept of logical queues is proposed in this RIP, which enables RocketMQ
> to have the ability to scale in seconds without changing the number of
> queues.
>
> The vote will be open for at least 72 hours or until a necessary number
> of votes are reached.
>
> Please vote accordingly:
>
> [ ] +1 approve
> [ ] +0 no opinion
> [ ] -1 disapprove with the reason
>
>
>
> ayanamist  于2021年5月18日周二 上午10:14写道：
>
>> Below is Markdown text with some GFM syntax.
>>
>> # Status
>> - Current State: Proposed
>> - Authors: [ayanamist](https://github.com/ayanamist)
>> - Shepherds: duhengfore...@apache.org
>> - Mailing List discussion: dev@rocketmq.apache.org
>> - Pull Request: #PR_NUMBER
>> - Released: 
>> # Background & Motivation
>> What do we need to do
>> - Will we add a new module?
>> No.
>> - Will we add new APIs?
>> It will add a new constant to mock broker names for logical queues.
>> - Will we add a new feature?
>> Yes.
>>
>> Why should we do that
>> - Are there any problems with our current project?
>> Currently, the MessageQueue of RocketMQ is coupled with broker name, which
>> results that the queue number will change if broker number increases or
>> decreases, which causes all queues to rebalance, which may cause service
>> disruption like flink job restarts in minutes.
>> - What can we benefit from proposed changes?
>> The number of logical queues is not related with the number of brokers: We
>> can increase broker number without changing logical queue number,
>> moreover,
>> we can increase logical queue number without deploying a new broker.
>> # Goals
>> - What problem is this proposal designed to solve?
>> Provide an abstraction, logical queue, to decouple between queue number
>> and
>> broker number.
>> - To what degree should we solve the problem?
>> We should not hurt availability or performance in the implementation.
>> # Non-Goals
>> - What problem is this proposal NOT designed to solve?
>> We will not improve the mechanism of queues rebalance.
>> - Are there any limits of this proposal?
>> Only newer clients with changes in this proposal will benefit.
>> # Changes
>> ## Architecture
>>
>> We use one or more MessageQueue to make one LogicalQueue; One LogicalQueue
>> is unique in one topic, and one MessageQueue belongs to one and only one
>> LogicalQueue.
>>
>> | brokerName | MessageQueue | LogicalQueue |
>> ||--|--|
>> | broker1| 0| 0|
>> | broker1| 1| 1|
>> | broker2| 0| 2|
>> | broker2| 1| 3|
>>
>> After one LogicalQueue migrated from broker1 to broker2, there will be two
>> MessageQueues for one LogicalQueue. We only migrate mapping but not actual
>> data, so broker1 is still serving for old data consuming but not data
>> producing.
>>
>> | brokerName | MessageQueue | LogicalQueue | QueueStatus |
>> ||--|--||
>> | **broker1**| **0**| **0(0-100)** | **ReadOnly**
>> |
>> | broker1| 1| 1| Normal |
>> | broker2| 0| 2| Normal |
>> | broker2| 1| 3| Normal |
>> | **broker2**| **2**| **0(101-)** | **Normal**
>> |
>>
>> After broker1 cleans all data from the commit log and consume queue,
>> QueueStatus becomes Expired(neither readable nor writable).
>>
>> | brokerName | MessageQueue | LogicalQueue | QueueStatus |
>> ||--|--|-|
>> | **broker1**| **0**| **0(-)** | **Expired** |
>> | broker1| 1| 1| Normal  |
>> | broker2| 0| 

Re: [External Mail]Re: [VOTE] RIP-21 RocketMQ Logical Queue

[heng du]

+1

dongeforever  于2021年6月1日周二 下午2:18写道：

> +1
> Nice.
> LogicQueue is a great feature and will bring new capabilities for RocketMQ.
>
> Xu16 Zhang 张旭  于2021年6月1日周二 下午12:04写道：
>
> > +1
> >
> >
> >
> > 
> > 张旭
> > 人工智能与云平台-云技术-计算平台组
> > 电话: 15011056041
> >
> > 
> > 发件人: zhibo li 
> > 发送时间: 2021年5月31日 15:00
> > 收件人: dev@rocketmq.apache.org
> > 主题: [External Mail]Re: [VOTE] RIP-21 RocketMQ Logical Queue
> >
> > *外部邮件，谨慎处理 | This message originated from outside of XIAOMI. Please treat
> > this email with caution*
> >
> >
> > +1
> >
> > heng du  于2021年5月29日周六 上午9:55写道：
> >
> > > Hi RocketMQ Community,
> > >
> > > This is the vote for the kickoff of RIP-21 RocketMQ logic queue.
> > >
> > > In order to better meet the needs of stream computing and scaling, the
> > > concept of logical queues is proposed in this RIP, which enables
> RocketMQ
> > > to have the ability to scale in seconds without changing the number of
> > > queues.
> > >
> > > The vote will be open for at least 72 hours or until a necessary number
> > > of votes are reached.
> > >
> > > Please vote accordingly:
> > >
> > > [ ] +1 approve
> > > [ ] +0 no opinion
> > > [ ] -1 disapprove with the reason
> > >
> > >
> > >
> > > ayanamist  于2021年5月18日周二 上午10:14写道：
> > >
> > > > Below is Markdown text with some GFM syntax.
> > > >
> > > > # Status
> > > > - Current State: Proposed
> > > > - Authors: [ayanamist](https://github.com/ayanamist)
> > > > - Shepherds: duhengfore...@apache.org
> > > > - Mailing List discussion: dev@rocketmq.apache.org
> > > > - Pull Request: #PR_NUMBER
> > > > - Released: 
> > > > # Background & Motivation
> > > > What do we need to do
> > > > - Will we add a new module?
> > > > No.
> > > > - Will we add new APIs?
> > > > It will add a new constant to mock broker names for logical queues.
> > > > - Will we add a new feature?
> > > > Yes.
> > > >
> > > > Why should we do that
> > > > - Are there any problems with our current project?
> > > > Currently, the MessageQueue of RocketMQ is coupled with broker name,
> > > which
> > > > results that the queue number will change if broker number increases
> or
> > > > decreases, which causes all queues to rebalance, which may cause
> > service
> > > > disruption like flink job restarts in minutes.
> > > > - What can we benefit from proposed changes?
> > > > The number of logical queues is not related with the number of
> brokers:
> > > We
> > > > can increase broker number without changing logical queue number,
> > > moreover,
> > > > we can increase logical queue number without deploying a new broker.
> > > > # Goals
> > > > - What problem is this proposal designed to solve?
> > > > Provide an abstraction, logical queue, to decouple between queue
> number
> > > and
> > > > broker number.
> > > > - To what degree should we solve the problem?
> > > > We should not hurt availability or performance in the implementation.
> > > > # Non-Goals
> > > > - What problem is this proposal NOT designed to solve?
> > > > We will not improve the mechanism of queues rebalance.
> > > > - Are there any limits of this proposal?
> > > > Only newer clients with changes in this proposal will benefit.
> > > > # Changes
> > > > ## Architecture
> > > >
> > > > We use one or more MessageQueue to make one LogicalQueue; One
> > > LogicalQueue
> > > > is unique in one topic, and one MessageQueue belongs to one and only
> > one
> > > > LogicalQueue.
> > > >
> > > > | brokerName | MessageQueue | LogicalQueue |
> > > > ||--|--|
> > > > | broker1| 0| 0|
> > > > | broker1| 1| 1|
> > > > | broker2| 0| 2|
> > > > | broker2| 1| 3|
> > > >
> > > > After one LogicalQueue migrated from broker1 to broker2, there will
> be
> > > two
> > > &g

[VOTE] RIP-21 RocketMQ Logical Queue

[heng du]

Hi RocketMQ Community,

This is the vote for the kickoff of RIP-21 RocketMQ logic queue.

In order to better meet the needs of stream computing and scaling, the
concept of logical queues is proposed in this RIP, which enables RocketMQ
to have the ability to scale in seconds without changing the number of
queues.

The vote will be open for at least 72 hours or until a necessary number
of votes are reached.

Please vote accordingly:

[ ] +1 approve
[ ] +0 no opinion
[ ] -1 disapprove with the reason



ayanamist  于2021年5月18日周二 上午10:14写道：

> Below is Markdown text with some GFM syntax.
>
> # Status
> - Current State: Proposed
> - Authors: [ayanamist](https://github.com/ayanamist)
> - Shepherds: duhengfore...@apache.org
> - Mailing List discussion: dev@rocketmq.apache.org
> - Pull Request: #PR_NUMBER
> - Released: 
> # Background & Motivation
> What do we need to do
> - Will we add a new module?
> No.
> - Will we add new APIs?
> It will add a new constant to mock broker names for logical queues.
> - Will we add a new feature?
> Yes.
>
> Why should we do that
> - Are there any problems with our current project?
> Currently, the MessageQueue of RocketMQ is coupled with broker name, which
> results that the queue number will change if broker number increases or
> decreases, which causes all queues to rebalance, which may cause service
> disruption like flink job restarts in minutes.
> - What can we benefit from proposed changes?
> The number of logical queues is not related with the number of brokers: We
> can increase broker number without changing logical queue number, moreover,
> we can increase logical queue number without deploying a new broker.
> # Goals
> - What problem is this proposal designed to solve?
> Provide an abstraction, logical queue, to decouple between queue number and
> broker number.
> - To what degree should we solve the problem?
> We should not hurt availability or performance in the implementation.
> # Non-Goals
> - What problem is this proposal NOT designed to solve?
> We will not improve the mechanism of queues rebalance.
> - Are there any limits of this proposal?
> Only newer clients with changes in this proposal will benefit.
> # Changes
> ## Architecture
>
> We use one or more MessageQueue to make one LogicalQueue; One LogicalQueue
> is unique in one topic, and one MessageQueue belongs to one and only one
> LogicalQueue.
>
> | brokerName | MessageQueue | LogicalQueue |
> ||--|--|
> | broker1| 0| 0|
> | broker1| 1| 1|
> | broker2| 0| 2|
> | broker2| 1| 3|
>
> After one LogicalQueue migrated from broker1 to broker2, there will be two
> MessageQueues for one LogicalQueue. We only migrate mapping but not actual
> data, so broker1 is still serving for old data consuming but not data
> producing.
>
> | brokerName | MessageQueue | LogicalQueue | QueueStatus |
> ||--|--||
> | **broker1**| **0**| **0(0-100)** | **ReadOnly**
> |
> | broker1| 1| 1| Normal |
> | broker2| 0| 2| Normal |
> | broker2| 1| 3| Normal |
> | **broker2**| **2**| **0(101-)** | **Normal**
> |
>
> After broker1 cleans all data from the commit log and consume queue,
> QueueStatus becomes Expired(neither readable nor writable).
>
> | brokerName | MessageQueue | LogicalQueue | QueueStatus |
> ||--|--|-|
> | **broker1**| **0**| **0(-)** | **Expired** |
> | broker1| 1| 1| Normal  |
> | broker2| 0| 2| Normal  |
> | broker2| 1| 3| Normal  |
> | broker2| 2| 0(101-)  | Normal  |
>
> If this LogicalQueue is migrated back to broker1, it will reuse this
> expired MessageQueue
>
> | brokerName | MessageQueue | LogicalQueue | QueueStatus |
> ||--|--|-|
> | **broker1**| **0**| **0(201-)**  | **Normal**  |
> | broker1| 1| 1| Normal  |
> | broker2| 0| 2| Normal  |
> | broker2| 1| 3| Normal  |
> | **broker2**| **2**| **0(101-200)**   | **ReadOnly**|
>
> If this LogicalQueue is migrated back to broker1 while MessageQueue not
> expired, it will create a new MessageQueue
>
> | brokerName | MessageQueue | LogicalQueue | QueueStatus |
> ||--|--|-|
> | **broker1**| **0**| **0(0-100)** | **ReadOnly**|
> | broker1| 1| 1| Normal  |
> | **broker1**| **2**| **0(201-)**  | 

Re: [VOTE]Release Apache RocketMQ Client Go Native 2.1.0.

[heng du]

+1

[ ok]  Checksums and PGP signatures are valid for the Source package.

[ ok] Source code artifacts have correct names matching the current release.

[ ok] License and Notice are correct in the source package.

[ ok]  All files have license headers in the source package if necessary.

[ ok]   No compiled archives bundled in the source archive.

[ ok] Hash and Tag in GitHub repo are matching the current artifacts.

胡 宗棠  于2021年3月19日周五 上午10:31写道：

> +1
> checked
>
> 
> 发件人: zhang xu 
> 发送时间: 2021年3月18日 22:10
> 收件人: dev@rocketmq.apache.org 
> 主题: Re: [VOTE]Release Apache RocketMQ Client Go Native 2.1.0.
>
> +1
> checked
>
> [ OK ]  Source code artifacts have correct names matching the current
> release.
>
> [ OK ]  License and Notice are correct in the source package.
>
> [ OK ]  All files have license headers in the source package if necessary.
>
> [ OK ]  No compiled archives bundled in the source archive.
>
> [ OK ]  Hash and Tag in GitHub repo are matching the current artifacts.
>
> ShannonDing  于2021年3月18日周四 下午9:09写道：
>
> > Hello RocketMQ Community,
> >
> >
> >
> > This is the vote for version 2.1.0 of Apache RocketMQ Client Go Native.
> >
> > The main goal of this release is to improve stability, usability, and fix
> > bugs and the source code of this release is the copy of the master which
> > has merged from the native branch before.
> >
> > The artifacts:
> >
> >
> >
> https://dist.apache.org/repos/dist/dev/rocketmq/rocketmq-client-go/2.1.0-rc6/
> >
> > Git tag for the release:
> >
> > https://github.com/apache/rocketmq-client-go/releases/tag/v2.1.0
> >
> > The hash for the release tag:
> >
> > d6e66a2d648d6529eca833f9bf912915d1749a5c
> >
> > Release Notes:
> >
> >
> >
> http://rocketmq.apache.org/release_notes/release-notes-rocketmq-client-go-2.1.0/
> >
> > The artifacts have been signed with Key :
> >
> > BC9E172DE1BA5B24EBB4A628177B55985D75751B, which can be found in the keys
> > file:
> >
> > https://dist.apache.org/repos/dist/dev/rocketmq/KEYS
> >
> >
> >
> >
> > Checklist for reference,
> >
> > Note that this is not an official policy but may help with checking
> > releases.
> >
> > Fill in the following:
> >
> > [ ]  Checksums and PGP signatures are valid for the Source package.
> >
> > [ ]  Source code artifacts have correct names matching the current
> release.
> >
> > [ ]  License and Notice are correct in the source package.
> >
> > [ ]  All files have license headers in the source package if necessary.
> >
> > [ ]  No compiled archives bundled in the source archive.
> >
> > [ ]  Hash and Tag in GitHub repo are matching the current artifacts.
> >
> > As we don’t release binary packages for Apache RocketMQ Go SDK, the
> binary
> > package checklist should not be followed.
> >
> > And any other checkpoint is welcomed and please feel free to reply to
> this
> > email, we sincerely hope for your feedback.
> >
> >
> >
> >
> > The vote will be open for at least 72 hours or until the necessary number
> > of votes are reached.
> >
> > Please vote accordingly:
> >
> >
> >
> >
> > [ ] +1 approve
> >
> > [ ] +0 no opinion
> >
> > [ ] -1 disapprove with the reason
> >
> >
> >
> >
> > Thanks,
> >
> > The Apache RocketMQ Team
>

[DISCUSS] Flink-RocketMQ connector

[heng du]

Apache RocketMQ[1], as a cloud-native messaging and streaming platform, has
a large number of users [2] all over the world, especially in China.


Recently, more and more users have begun to use RocketMQ to integrate with
Flink, which has resulted in a large number of issues[3] and PRs[4]. So,
RocketMQ community contributors implemented a Connector for RocketMQ-Flink,
which is now maintained in the Apache RocketMQ repository[5], So far, the
connector is being used by cloud vendors as well as Internet companies.


In order to attract more developers from the Flink community to participate
in this Connector improvement, we hope to merge this connector back to the
Flink repository[6], at the same time, we will continue to polish the
existing implementation and add new features, such as table connector
support, and welcome more and more developer to work together with us to
improve this connector.


Thanks

Henry


[1] https://rocketmq.apache.org/

[2] https://rocketmq.apache.org/users/

[3] https://github.com/apache/rocketmq-externals/issues?q=is%3Aissue+flink+

[4] https://github.com/apache/rocketmq-externals/pulls?q=is%3Apr+flink

[5] https://github.com/apache/rocketmq-externals/tree/master/rocketmq-flink

[6] https://github.com/apache/flink

Re: [VOTE]Release Apache RocketMQ Spring 2.2.0 RC1

[heng du]

+1

checked：
 [ok]  Source code artifacts have correct names matching the current
release.
 [ok]  License and Notice are correct in source package.
 [ok]  All files have license headers in source package if necessary.
 [ok]  No compiled archives bundled in source archive.
 [ok]  Hash and Tag in GitHub repo are matching the current artifacts.
 [ok]  The code can be built success in the source package and it works
well.


zhibo li  于2021年1月18日周一 上午10:59写道：

> +1
>
> jinrongtong  于2021年1月8日周五 下午7:23写道：
>
> > Hello RocketMQ Community,
> >
> > This is the vote for the 2.2.0 release of Apache RocketMQ-Spring.
> >
> >
> > The artifacts:
> >
> https://dist.apache.org/repos/dist/dev/rocketmq/rocketmq-spring/2.2.0-rc1/
> >
> >
> > The staging repo:
> >
> https://repository.apache.org/content/repositories/orgapacherocketmq-1050
> >
> >
> > Git tag for the release:
> >
> >
> https://github.com/apache/rocketmq-spring/releases/tag/rocketmq-spring-all-2.2.0
> >
> >
> > Hash for the release tag:
> > 66a6d8b51c6202b14195b1ac1a4311a7ce3e81dc
> >
> >
> > Release Notes:
> >
> >
> http://rocketmq.apache.org/release_notes/release-notes-rocketmq-spring-2.2.0/
> >
> >
> > The artifacts have been signed with Key :
> > EC9F268B4C20590138B11FE701420E4292296EAE, which can be found in the keys
> > file:
> > https://dist.apache.org/repos/dist/dev/rocketmq/KEYS
> >
> >
> > Checklist for reference,
> > Note that this is not an official policy but may help with checking
> > releases.
> > Fill in the following:
> > [ ]  Checksums and PGP signatures are valid for source package.
> > [ ]  Source code artifacts have correct names matching the current
> release.
> > [ ]  License and Notice are correct in source package.
> > [ ]  All files have license headers in source package if necessary.
> > [ ]  No compiled archives bundled in source archive.
> > [ ]  Hash and Tag in GitHub repo are matching the current artifacts.
> > [ ]  The code can be built success in the source package.
> >
> >
> > And any other checkpoint is welcomed and please feel free to reply to
> this
> > email, we sincerely hope for your feedback.
> > The vote will be open for at least 72 hours or until a necessary number
> of
> > votes are reached.
> >
> >
> > Please vote accordingly:
> > [ ] +1 approve
> > [ ] +0 no opinion
> > [ ] -1 disapprove with the reason
> >
> >
> >
> >
> > Thanks,
> > The Apache RocketMQ Team
>

[VOTE] RIP-19 RocketMQ Pop Consuming

[heng du]

Hi RocketMQ Community,

This is the vote for the kickoff of RIP-19 RocketMQ Pop Consuming.

In order to better implement a lightweight client, @ayanamist proposes a
new consumption model, and at the same time transfers the load balancing
logic of the original client to the broker, which not only solves the
original queue occupancy problem but also It can also avoid the consumption
delay caused by a certain consumer hangs.

The vote will be open for at least 72 hours or until a necessary number of
votes are reached.

Please vote accordingly:

[ ] +1 approve
[ ] +0 no opinion
[ ] -1 disapprove with the reason




Best Regards!
Henry

ayanamist  于2021年1月8日周五 上午11:25写道：

> # RIP-19 RocketMQ Pop Consuming
>
> # Status
>
> - Current State: Proposed
> - Authors: [ayanamist]([
> https://github.com/ayanamist/](https://github.com/ayanamist/))
> - Shepherds: [duhengforever]([
> https://github.com/duhenglucky/](https://github.com/duhengforever/))
> - Mailing List discussion: dev@rocketmq.apache.org;
> us...@rocketmq.apache.org
> - Pull Request: RIP-19
> - Released: -
>
> # Background & Motivation
>
> ### What do we need to do
>
> - Will we add a new module?
>
> No.
>
> - Will we add new APIs?
>
> Yes.
>
> - Will we add new feature?
>
> Yes.
>
> ### Why should we do that
>
> - Are there any problems of our current project?
>
> The current subscription load balancing strategy is based on the
> dimension of message queue. All behaviors are owned by the client side.
> There are three main steps:
>
> 1. Each consumer regularly obtains the total number of topic message
> queues and all consumers.
> 2. Using a general algorithm to sort the queues by consumer ip and
> queue index to calculate which message queue is allocated to which
> consumer.
> 3. Each consumer pulls messages using allocated orders described above.
>
> According to this allocation method, if an abnormality occurs in a
> consumer (the application itself is abnormal, or a broker is upgrading) so
> that it causes slow subscription, messages will be accumulated, but this
> queue will not be re-allocated to another consumer, so the accumulation
> will become more and more serious.
>
>
> Chinese version:
>
> 当前的消费负载均衡策略是以队列的维度来进行，所有行为全部是由客户端主动来完成，主要分为三步：
>
> 1. 每个consumer定时去获取消费的topic的队列总数，以及consumer总数
> 2. 将队列按编号、consumer按ip排序，用统一的分配算法计算该consumer分配哪些消费队列
> 3. 每个consumer去根据算法分配出来的队列，拉取消息消费
>
>
>
> 按照这个分配方式，如果有一个队列有异常（应用自身异常，或某个broker在升级）导致消费较慢或者停止，该队列会出现堆积现象，因为队列不会被分配给其他机器，因此如果长时间不处理，队列的堆积会越来越严重。
>
> - What can we benefit proposed changes?
>
> The accumulated messages will be subscribed by other consumers if one
> consumer behaves abnormally.
>
> Chinese version:
>
> 在某个队列消费异常的情况下，可以快速的由其它消费者接手进行消费，缓解堆积状态。
>
> # Goals
>
> - What problem is this proposal designed to solve?
>
> The accumulated messages will be subscribed by other consumers if one
> consumer behaves abnormally.
>
> Chinese version:
>
> 在某个队列消费异常的情况下，可以快速的由其它消费者接手进行消费，缓解堆积状态。
>
> - To what degree should we solve the problem?
>
> This RIP must guarantee below point:
>
> 1. High availablity: Subscription of one message queue will not be
> affected by single consumer failure.
> 2. High performance: This implementation affects latency and throughput
> less than 10%.
>
>
> Chinese version:
>
> 新方案需要保证两点：
>
> 1. 高可用：单一队列的消费能力不受某个消费客户端异常的影响
> 2. 高性能：POP订阅对消息消费的延迟和吞吐的影响在10%以内
>
> # Non-Goals
>
> - What problem is this proposal NOT designed to solve?
>
> Improve client-side load balancing.
>
> - Are there any limits of this proposal?
>
> Nothing specific.
>
> # Changes
>
> ## Architecture
>
> Current "Pull mode":
> ![pull](
>
> https://user-images.githubusercontent.com/406779/103756075-cc93b900-5049-11eb-8fae-cfe5398ebaad.png
> )
>
> Proposed "Pop mode":
> ![pop](
>
> https://user-images.githubusercontent.com/406779/103757230-6d36a880-504b-11eb-95d5-7e8cff8cdef1.png
> )
>
> Move inter-queue balance of one topic from client side to server side.
> Clients make pull request without specified queues to broker, and broker
> fetch messages from queues internally and returns, which ensures one queue
> will be consumed by multiple clients. The whole behavior is like a queue
> pop process.
>
> It will add a new request command querying queue assignments in broker, and
> add pop-feature-support flag to pull request which makes broker use pop
> mode.
>
> ## Interface Design/Change
>
> - Method signature changes
>
> Nothing specific.
>
> - Method behavior changes
>
> Nothing specific.
>
> - CLI command changes
>
> Add `setConsumeMode` for admin to switch between old pull mode and new
> pop mode for one subscription.
>
> - Log format or content changes
>
> Nothing specific.
>
> ## Compatibility, Deprecation, and Migration Plan
>
> - Are backward and forward compatibility taken into consideration?
>
> New RequestCode between client and broker are added, so there are 2
> compatibility 

Re: [VOTE]Release Apache RocketMQ 4.8.0 RC1

[heng du]

+1

I have checked:
[ok]  Start nameserver and broker according to the quick-start
[ok]  Run clusterList command to see if the version is correct
[ok]  Checksums and PGP signatures are valid for Source package.
[ok]  Checksums and PGP signatures are valid for Binary package.
[ok]  Source code artifacts have correct names matching the current release.
[ok]  Binary artifacts have correct names matching the current release.
[ok]  License and Notice are correct in source package.
[ok]  License and Notice are correct in binary package.
[ok]  All files have license headers in source package if necessary.
[ok]  Hash and Tag in GitHub repo is matching the current artifacts.


tiger lee  于2020年12月18日周五 下午9:18写道：

> +1
>
> Rongtong Jin  于2020年12月16日周三 下午7:27写道：
>
> > +1
> >
> > I checked:
> > [OK]  Source code artifacts have correct names matching the current
> > release.
> > [OK]  Hash and Tag in GitHub repo is matching the current artifacts.
> > [OK]  The code can be built success in the source package.
> > [OK]  Start nameserver and broker according to the quick-start
> > [OK]  Run clusterList command to see if the version is correct
> >
> > jinrongtong jinrongt...@apache.org写道：
> > > Hello RocketMQ Community,
> > >
> > > This is the vote for 4.8.0 of Apache RocketMQ.
> > >
> > > This release has made a lot of optimizations to the DLedger mode,
> > including supporting batch messages, optimizing replication to improve
> > performance, and fixing important bugs. This release made some
> > enhancements, such as adding a query message trace command, using
> > CopyOnWriteArrayList to avoid possible thread safety issues. Finally,
> this
> > release optimized a large number of documents and code style.
> > >
> > >
> > > The artifacts:
> > > https://dist.apache.org/repos/dist/dev/rocketmq/4.8.0-rc1/
> > >
> > >
> > > The staging repo:
> > >
> >
> https://repository.apache.org/content/repositories/orgapacherocketmq-1049
> > >
> > >
> > > Git tag for the release:
> > > https://github.com/apache/rocketmq/tree/release-4.8.0
> > >
> > >
> > > Hash for the release tag:
> > > 39bb9386f10d5d8dfe81183c172a3a86f6d313bd
> > >
> > >
> > > Release Notes:
> > > https://rocketmq.apache.org/release_notes/release-notes-4.8.0/
> > >
> > >
> > > The artifacts have been signed with Key
> > > EC9F268B4C20590138B11FE701420E4292296EAE, which can be found in the
> keys
> > file:
> > > https://dist.apache.org/repos/dist/dev/rocketmq/KEYS
> > >
> > >
> > >
> > >
> > > Checklist for reference,
> > > Note that this is not an official policy but may help with checking
> > releases.
> > > Fill in the following:
> > >
> > >
> > > []  Checksums and PGP signatures are valid for Source package.
> > > []  Checksums and PGP signatures are valid for Binary package.
> > > []  Source code artifacts have correct names matching the current
> > release.
> > > []  Binary artifacts have correct names matching the current release.
> > > []  License and Notice are correct in source package.
> > > []  License and Notice are correct in binary package.
> > > []  All files have license headers in source package if necessary.
> > > []  No compiled archives bundled in source archive.
> > > []  Hash and Tag in GitHub repo is matching the current artifacts.
> > > []  The code can be built success in the source package.
> > > []  Start nameserver and broker according to the quick-start
> > > []  Run clusterList command to see if the version is correct
> > >
> > >
> > > And any other check point is welcomed and please feel free to reply to
> > this email, we sincerely hope to your feedback.
> > > The vote will be open for at least 72 hours or until necessary number
> of
> > votes are reached.
> > >
> > >
> > > Please vote accordingly:
> > >
> > >
> > > [ ] +1 approve
> > > [ ] +0 no opinion
> > > [ ] -1 disapprove with the reason
> > >
> > >
> > >
> > >
> > > Thanks,
> > > The Apache RocketMQ Team
> >
>

Re: [DISSCUSS] RIP-18 Metadata management architecture upgrade

[heng du]

@Jianhai

It is better to unify the message model with the KV model to store
metadata(eg. compact topic). would you like to submit a proposal in this
point?

Xu Jianhai  于2020年5月6日周三 下午3:04写道：

> maybe we could build openmessaging-kv based on DLedger,  and then rocketmq
> nameserver  uses openmessaging-kv to construct raft consensus.
>
> On Thu, Apr 30, 2020 at 3:29 PM 金融通 
> wrote:
>
> > Hi RocketMQ Community,
> >
> > I think it is a good choice to start the evolution of architecture for
> > RocketMQ with Metadata management architecture upgrade.
> >
> > Currently, the metadata consistency of RocketMQ is maintained by full
> > connection. For example, each broker registers with each nameserver to
> > ensure that the view of routing information seen between nameservers is
> the
> > same, and each consumer instance sends heartbeats (carrying subscription
> > information) to broker to ensure that the view of subscription
> information
> > seen between brokers is the same. However, such consistency maintenance
> is
> > weak. Unreliable network and delay may cause inconsistent views, which
> has
> > caused a lot ofissues.
> >
> > On the other hand, after RocketMQ 4.5.0, we have used the Raft protocol
> > (DLedger) to solve the consistency problem of log replication. DLedger
> is a
> > raft-based log storage library. At the beginning of the design, we hoped
> to
> > apply it to consistent metadata storage. If the metadata of RocketMQ is
> > stored as log and the consistency is guaranteed by using the raft
> protocol
> > (DLedger), the issue of metadata consistency will be solved.
> >
> > So I submitted RIP-18 Metadata management architecture upgrade, which
> > describes the specific plan in more detail. I hope to hear more voices
> from
> > the community. So please tell me your thoughts by replying to this email
> or
> > commenting on google docs.
> >
> > Best Regards!
> > Rongtong Jin
> >
> > RIP-18 Metadata management architecture upgrade
> >
> >
> https://docs.google.com/document/d/1hQxlbtlMDwNxyVDGsIIUpDNWwfS6hP0PGKY9-A2KUOA/edit?usp=sharing
> >
> >
> >  -原始邮件-
> >  发件人: "Gosling Von" 
> >  发送时间: 2019-01-30 17:54:47 (星期三)
> >  收件人: dev 
> >  抄送:
> >  主题: [DISCUSS] Thought of The Evolution of The Next Decade
> > Architecture for RocketMQ
> > 
> >  Hi,
> > 
> >  I would like to say happy new year to everyone, especially for the
> > guys from the eastern hemisphere. I think that when you see this topic,
> you
> > already know what I want to say :-)
> > 
> >  After more than 6 years of inspection from the community and market,
> > Apache RocketMQ has been widely used in the field of financial and
> > e-commerce online transactions. Known know data has shown that, just in
> > China, RocketMQ covers more than 40% of the traditional messaging scene.
> > With the globalization of the community in the past two years, this
> > development has spread to all of the worlds. However, through continuous
> > community activities, including technical exchanges with some of the
> > experts from the Microsoft, Berkeley, etc., coupled with the emergence of
> > IoT, AI, Blockchain and other scenarios around the world, I began to
> think
> > about the architecture evolution for RocketMQ. I hope we could make it as
> > the data infrastructure of cloud computing era. and we could better serve
> > in the next decade.
> > 
> > 
> >  First of all, the overall architecture will take the separation of
> > storage computing and pluggable architecture. Regarding the separation of
> > storage computing, I know that this is a controversial topic in the
> > industry. You may also see that Twitter had gave up their messaging
> > solution EventBus, which serving and storage layers are decoupled. one of
> > the important reason which is given by "introduces an additional hop".
> > That's right, usually, you don't need so much. But what I want to express
> > here is that the value of storage computing separation is just like the
> > single responsibility in our design pattern, so that focus is more
> focused.
> > For example, if messaging engine is deployed in the edge, we could
> arrange
> > computing nodes to be deployed on demand. Because it is a computationally
> > intensive task, we can focus on how to improve computing power and
> response
> > speed without concerned about the machine cost, operation and maintenance
> > cost brought by storage. Another case, RocketMQ storage is regarded as a
> > kind of time series storage. It not only provides the storage capacity of
> > single data, but also the capacity of bulk storage, but in any case it
> is a
> > data type independent sequential additional storage. Under this
> > architecture, if you want to realize the current transaction capability,
> > there are still some complications, especially when you want to make
> > RocketMQ a one-stop microservice transaction solution. We have already
> > tried this. Known feedback from the bank is, they have made some
> > modifications to the 

[DISCUSS]Apache RocketMQ quarter‘s report

[heng du]

Hi developers,
I am drafting RocketMQ quarter's report which will be due in a few days.
Please proof-read and feedback if there is a need.

## Description:
The mission of Apache RocketMQ is the creation and maintenance of software
related to fast, low latency, reliable, scalable, distributed, easy to use
message-oriented middleware, especially for processing large amounts of
streaming data

## Issues:
 There are no issues requiring board attention at this time.

## Membership Data:
Apache RocketMQ was founded 2017-09-20 (3 years ago)
There are currently 33 committers and 14 PMC members in this project.
The Committer-to-PMC ratio is roughly 9:4.

Community changes, past quarter:
- No new PMC members. Last addition was Rongtong Jin on 2020-03-30.
- Yufei Zhang was added as committer on 2020-08-18
- Rui Liu was added as committer on 2020-08-05

## Project Activity:
ROCKETMQ-SPRING-2.1.1 was released on 2020-07-24.
ROCKETMQ-4.7.1 was released on 2020-06-29.
ROCKETMQ-CLIENT-GO-2.0.0 was released on 2020-04-03

## Community Health:
RocketMQ community health is overall good as we see multiple improvements
proposals are being discussed in parallel and most issues/PRs are timely
responded.  The RocketMQ community is currently actively optimizing the
consumer load balancing architecture. In accordance with the cloud-native
technical trend, RocketMQ also evolves that way. Currently,
rocketmq-operator has gained official support from the operator community.

mailing list:
us...@rocketmq.apache.org had a 85% increase in traffic in the past quarter.
dev@rocketmq.apache.org had a 13% decrease in traffic in the past quarter.


Thanks

Re: [VOTE]Release RocketMQ Spring 2.1.1 RC1

[heng du]

Hi,

+1 (binding)

[ok]  The code can be built success in the source package
[ok]  Send and receive messages with the broker.
[ok]  Source code artifacts have correct names matching the current release.
[ok]  No compiled archives bundled in the source archive.



Justin Mclean  于2020年7月23日周四 下午5:02写道：

> Hi,
>
> +1 (binding)
>
> I checked:
> - signatures and hashes are correct
> - LICENSE and NOTICE are correct
> - All file have ASF headers
> - No binary files
> - can compile from source
>
> Thanks,
> Justin
>

Re: [RESTART][VOTE][#1] Release Apache RocketMQ 4.7.1 RC2

[heng du]

+1

checked:
[OK]  Checksums and PGP signatures are valid for Source package.
[OK]  Checksums and PGP signatures are valid for Binary package.
[OK]  Source code artifacts have correct names matching the current release.
[OK]  Binary artifacts have correct names matching the current release.
[OK]  License and Notice are correct in source package.
[OK]  License and Notice are correct in binary package.
[OK]  All files have license headers in source package if necessary.
[OK]  No compiled archives bundled in source archive.
[OK]  Hash and Tag in GitHub repo is matching the current artifacts.
[OK]  The code can be built success in the source package.
[OK]  Start nameserver and broker according to the quick-start
[OK]  Run clusterList command to see if the version is correct

Brant Lin <42645...@qq.com> 于2020年6月28日周日 下午2:23写道：

> +1
> I checked：
> [OK] License and Notice are correct in binary package.
> [OK] All files have license headers in source package if necessary.
> [OK] Hash and Tag in GitHub repo is matching the current artifacts.
> [OK] The code can be built success in the source package.
> [OK] Run clusterList command to see if the version is correct
>
>
> BR/Brant
> --原始邮件--
> 发件人:"金融通" 发送时间:2020年6月28日(星期天) 下午2:16
> 收件人:"dev"
> 主题:Re: [RESTART][VOTE][#1] Release Apache RocketMQ 4.7.1 RC2
>
>
>
> +1
>
> I checked:
> [OK] Checksums and PGP signatures are valid for Source package.
> [OK] Checksums and PGP signatures are valid for Binary package.
> [OK] Source code artifacts have correct names matching the current
> release.
> [OK] Hash and Tag in GitHub repo is matching the current artifacts.
>
>
> gt; -原始邮件-
> gt; 发件人: jinrongtong  gt; 发送时间: 2020-06-24 15:35:57 (星期三)
> gt; 收件人: dev@rocketmq.apache.org
> gt; 抄送:
> gt; 主题: [RESTART][VOTE][#1] Release Apache RocketMQ 4.7.1 RC2
> gt;
> gt; Hello RocketMQ Community,
> gt;
> gt; This is the vote for 4.7.1 of Apache RocketMQ.
> gt;
> gt; This release made some enhancements, such as the upgrade of
> fastjson version, improving the security of the system topic operation,
> optimizing master-slave replication, pull consumer, etc. This release also
> fixed issue about request-reply message. Finally, this release optimized a
> large number of documents and code style.
> gt;
> gt;
> gt; The artifacts:
> gt; https://dist.apache.org/repos/dist/dev/rocketmq/4.7.1-rc2/
> gt
> ;
> gt;
> gt; The staging repo:
> gt;
> https://repository.apache.org/content/repositories/orgapacherocketmq-1047
> gt
> ;
>
> gt;
> gt; Git tag for the release:
> gt; https://github.com/apache/rocketmq/commits/release-4.7.1
> gt ;
>
> gt;
> gt; Hash for the release tag:
> gt; 9f95a972e10e0681bc3f2d00e9957aa212e897b5
> gt;
> gt;
> gt; Release Notes:
> gt; https://rocketmq.apache.org/release_notes/release-notes-4.7.1/
> gt
> ;
> gt;
> gt; The artifacts have been signed with Key
> gt; EC9F268B4C20590138B11FE701420E4292296EAE, which can be found in
> the keys file:
> gt; https://dist.apache.org/repos/dist/dev/rocketmq/KEYS
> gt;
> gt;
> gt; Checklist for reference,
> gt; Note that this is not official policy but may help with checking
> releases.
> gt; Fill in the following:
> gt; [] Checksums and PGP signatures are valid for Source
> package.
> gt; [] Checksums and PGP signatures are valid for Binary
> package.
> gt; [] Source code artifacts have correct names matching the
> current release.
> gt; [] Binary artifacts have correct names matching the current
> release.
> gt; [] License and Notice are correct in source package.
> gt; [] License and Notice are correct in binary package.
> gt; [] All files have license headers in source package if
> necessary.
> gt; [] No compiled archives bundled in source archive.
> gt; [] Hash and Tag in GitHub repo is matching the current
> artifacts.
> gt; [] The code can be built success in the source package.
> gt; [] Start nameserver and broker according to the quick-start
> gt; [] Run clusterList command to see if the version is correct
> gt;
> gt;
> gt; And any other check point is welcomed and please feel free to
> reply to this email, we sincerely hope to your feedback.
> gt;
> gt;
> gt; The vote will be open for at least 72 hours or until necessary
> number of votes are reached.
> gt;
> gt;
> gt; Please vote accordingly:
> gt; [ ] +1 approve
> gt; [ ] +0 no opinion
> gt; [ ] -1 disapprove with the reason
> gt;
> gt;
> gt; Thanks,
> gt; The Apache RocketMQ Team
> 

Re: Proposal for GSoC 2020

[heng du]

Hi, Badrul,

The great proposal, please keep moving.

Badrul Chowdhury  于2020年4月1日周三 上午1:18写道：

> Hi Henry,
>
> I went ahead and submitted the proposal. Please let me know if you need
> anything else from me.
>
> Thanks,
> Badrul
>
> On Wed, Mar 25, 2020 at 10:17 PM Badrul Chowdhury <
> badrulchowdhur...@gmail.com> wrote:
>
> > Hi Henry,
> >
> > I have modified my original proposal to use the RocketMQ Connect Runtime
> > in my new draft:
> >
> https://docs.google.com/document/d/10zo__rwoyzSQ8I-cEWvyvJGmGnKMkfLWUD2LzdfNdV8/edit?usp=sharing
> >
> > I would love to hear your thoughts on it.
> >
> > Thanks,
> > Badrul
> >
> > On Mon, Mar 23, 2020 at 8:53 PM Badrul Chowdhury <
> > badrulchowdhur...@gmail.com> wrote:
> >
> >> Thanks a lot for the feedback Henry!
> >>
> >> >> (3) In this project, you should not care about the specific
> >> implementation
> >> of message sending or receiving, because these are hidden by Connect
> >> Runtime, you only need to care about how to get and analyze the data of
> >> Cassandra.
> >>
> >> I agree, I missed the existing RocketMQ Connect framework completely.
> Did
> >> you want me to refactor my proposal to use the RocketMQ Connect
> framework
> >> before submitting? The alternative is to submit the proposal as is and
> >> change it as required when we start working on the implementation.
> >>
> >> Thanks,
> >> Badrul
> >>
> >> On Mon, Mar 23, 2020 at 6:19 PM heng du 
> wrote:
> >>
> >>> Hi, Badrul,
> >>>
> >>> Very sorry for the late reply, and I have read your proposal carefully,
> >>> and
> >>> you did a great job, but there are some suggestions for you:
> >>>
> >>> (1) We can start by implementing source connect, and then implement
> sink
> >>> connect if we have more time.
> >>> (2) In the process of implementation, some issues of the Connect
> Runtime
> >>> <
> >>>
> https://github.com/apache/rocketmq-externals/tree/master/rocketmq-connect
> >>> >
> >>> may be found at the same time. I hope we can polish it together.
> >>> (3) In this project, you should not care about the specific
> >>> implementation
> >>> of message sending or receiving, because these are hidden by Connect
> >>> Runtime, you only need to care about how to get and analyze the data of
> >>> Cassandra.
> >>>
> >>> And would you like to submit this proposal to the GSoC website?
> >>>
> >>> Thanks，
> >>> Henry
> >>>
> >>>
> >>> Badrul Chowdhury  于2020年3月23日周一 下午1:54写道：
> >>>
> >>> > Hi Henry,
> >>> >
> >>> > I hope you are well. I finally found some time this weekend to write
> >>> the
> >>> > proposal, please let me know what you think:
> >>> >
> >>> >
> >>>
> https://docs.google.com/document/d/1rm0OfeiD-HKopVs0JeUwMYsGimqDwHvI87MBaPd5yr8/edit?usp=sharing
> >>> >
> >>> > I look forward to your feedback!
> >>> >
> >>> > Stay safe,
> >>> >
> >>> > Thanks,
> >>> > Badrul
> >>> > On Sat, Mar 14, 2020 at 9:26 AM heng du 
> >>> wrote:
> >>> >
> >>> > > Hi, Badrul，
> >>> > >
> >>> > > Go ahead with your plan. I‘m all for it.
> >>> > >
> >>> > > Thanks，
> >>> > > Henry
> >>> > >
> >>> > > Badrul Chowdhury  于2020年3月14日周六
> >>> 上午1:36写道：
> >>> > >
> >>> > > > Thanks Henry! I will go ahead and submit a proposal for Cassandra
> >>> > > > connector. Can I share my proposal here for feedback?
> >>> > > >
> >>> > > > Thanks,
> >>> > > > Badrul
> >>> > > >
> >>> > > > On Wed, Mar 11, 2020 at 6:00 PM heng du <
> duhengfore...@apache.org>
> >>> > > wrote:
> >>> > > >
> >>> > > > > Hi, Badrul,
> >>> > > > >
> >>> > > > > Just follow your heart, find what you're good at, what you
> enjoy
> >>> :)
> >>> > > > >
> >>> > > > > Thanks,
> >>> > > > > Henry
> >>> > > > >
> >>> > > > > Badrul Chowdhury  于2020年3月12日周四
> >>> > 上午2:45写道：
> >>> > > > >
> >>> > > > > > Hi,
> >>> > > > > >
> >>> > > > > > I am looking to submit a proposal for GSoC 2020. I am very
> >>> > interested
> >>> > > > in
> >>> > > > > > contributing to developing a
> Hive/HBase/Cassandra/Elasticsearch
> >>> > > > > connector.
> >>> > > > > > I am wondering: is there a priority among these connectors?
> >>> > > > > >
> >>> > > > > > Thanks,
> >>> > > > > > Badrul
> >>> > > > > >
> >>> > > > >
> >>> > > >
> >>> > > >
> >>> > > > --
> >>> > > >
> >>> > > > Cheers,
> >>> > > > Badrul
> >>> > > >
> >>> > >
> >>> >
> >>> >
> >>> > --
> >>> >
> >>> > Cheers,
> >>> > Badrul
> >>> >
> >>>
> >>
> >>
> >> --
> >>
> >> Cheers,
> >> Badrul
> >>
> >
> >
> > --
> >
> > Cheers,
> > Badrul
> >
>
>
> --
>
> Cheers,
> Badrul
>

Re: [VOTE]Release Apache RocketMQ Client CPP 2.1.0 RC1.

[heng du]

+1 (binding)

checked:

-Checksums and PGP signatures are valid for the Source package.
-Checksums and PGP signatures are valid for the Binary package.
-Hash and Tag in GitHub repo are matching the current artifacts.
-Source code artifacts have correct names matching the current release.
-All necessary files have license headers


ShannonDing  于2020年3月25日周三 上午11:08写道：

>
>
> Hi,
> +1(binding)
> As the release manager, I checked the RC1 following the checklist.
> And any other check point is welcomed and please feel free to reply to
> this email, I sincerely hope to your feedback.
> On 03/23/2020 22:31，ShannonDing wrote：
>
>
>
> Hello RocketMQ Community,
>
> This is the vote for version 2.1.0 of Apache RocketMQ Client CPP.
>
> This release is a major upgrade, mainly including message tracing for pub
> and sub and support for higher version of GCC and add asan/lsan to check
> memories. The stability of the core is further improved.
>
> The artifacts:
>
>
> https://dist.apache.org/repos/dist/dev/rocketmq/rocketmq-client-cpp/2.1.0-rc1/
>
> Git tag for the release:
>
> https://github.com/apache/rocketmq-client-cpp/releases/tag/2.1.0
>
> Hash for the release tag:
>
> aee285fa1948d15cc1c6a70109a151bd044bc51a
>
> Release Notes:
>
>
> http://rocketmq.apache.org/release_notes/release-notes-rocketmq-client-cpp-2.1.0/
>
> The artifacts have been signed with Key :
>
> BC9E172DE1BA5B24EBB4A628177B55985D75751B, which can be found in the keys
>
> file: https://dist.apache.org/repos/dist/dev/rocketmq/KEYS
>
>
>
>
> Checklist for reference,
>
> Note that this is not official policy but may help with checking releases.
>
> Fill in the following:
>
> []  Checksums and PGP signatures are valid for Source package.
>
> []  Checksums and PGP signatures are valid for Binary package.
>
> []  Source code artifacts have correct names matching the current release.
>
> []  Binary artifacts have correct names matching the current release.
>
> []  License and Notice are correct in source package.
>
> []  License and Notice are correct in binary package.
>
> []  All files have license headers in source package if necessary.
>
> []  No compiled archives bundled in source archive.
>
> []  Hash and Tag in GitHub repo is matching the current artifacts.
>
> []  The code can be built success in the source package.
>
> And any other check point is welcomed and please feel free to reply to
> this email, we sincerely hope to your feedback.
>
>
>
>
> The vote will be open for at least 72 hours or until necessary number of
>
> votes are reached.
>
> Please vote accordingly:
>
>
>
>
> [] +1 approve
>
> [] +0 no opinion
>
> [] -1 disapprove with the reason
>
>
>
>
> Thanks,
>
> The Apache RocketMQ Team
>
>
>
>
>

Re: [COMDEV-342] Flink Connect GSoC Project

[heng du]

Hi, Nishadi,

Great work, and could you submit this proposal to the GSoC website?

Nishadi Kirielle Arachchillage  于2020年3月23日周一
上午5:36写道：

> Hi mentors and developers,
>
> I prepared an initial version of the GSoC proposal for Flink Table API
> connect.
>
>
> https://docs.google.com/document/d/1TXQk63A7Z29w3H1UlgQ3F297-opy2b2iBaVQHA6sjdo/edit?usp=sharing
>
> <https://docs.google.com/document/d/1TXQk63A7Z29w3H1UlgQ3F297-opy2b2iBaVQHA6sjdo/edit?usp=sharing>
> GSoC 2020 - Apache RocketMQ Flink Connect
> <https://docs.google.com/document/d/1TXQk63A7Z29w3H1UlgQ3F297-opy2b2iBaVQHA6sjdo/edit?usp=sharing>
> GSoC 2020 Proposal for Apache RocketMQ Flink Table Connect Project Apache
> RocketMQ Flink Table Connect Name Nishadi Kirielle University The
> Australian National University Email Address nishadi.kirie...@anu.edu.au
> Github https://github.com/nishadi LinkedIn https://www.linkedi...
> docs.google.com
> I am currently working on an initial prototype as well.
>
> I am really grateful for you if you can go through my proposal and let me
> know any feedback to improve.
>
> Thank you and best regards,
> Nishadi
>
>
> *Nishadi Kirielle*
>
> PhD Student,
>
> Research School of Computer Science,
>
> ANU College of Engineering and Computer Science,
> Australian National University, Canberra, ACT 2601, Australia.
>
> ------
> *From:* Nishadi Kirielle Arachchillage 
> *Sent:* Sunday, March 22, 2020 11:55 AM
> *To:* heng du ; dev@rocketmq.apache.org <
> dev@rocketmq.apache.org>
> *Cc:* nicholasji...@apache.org ;
> vongosl...@apache.org 
> *Subject:* Re: [COMDEV-342] Flink Connect GSoC Project
>
> Hi all,
>
> While working on the project, I could see that the existing rocketmq-flink<
> https://github.com/apache/rocketmq-externals/tree/master/rocketmq-flink>
> build fails with a Checkstyle issue and the Checkstyle file is outdated
> with the parent Checkstyle file.
> I created an issue for this and sent a pull request. It would be great if
> you can review it and merge it.
>
> https://github.com/apache/rocketmq-externals/issues/532
> https://github.com/apache/rocketmq-externals/pull/533
> [
> https://avatars3.githubusercontent.com/u/47359?s=400=4]<https://github.com/apache/rocketmq-externals/pull/533
> >
> [ISSUE #532] Fix Checkstyle issue in rocketmq-flink by nishadi · Pull
> Request #533 · apache/rocketmq-externals<
> https://github.com/apache/rocketmq-externals/pull/533>
> What is the purpose of the change #532 Fix the build failure due to
> Checkstyle issues in rocketmq-flink and update the checkstyle file as of
> the parent file located at apache/rocketmq/style/rmq_ch...
> github.com
>
> [
> https://avatars3.githubusercontent.com/u/47359?s=400=4]<https://github.com/apache/rocketmq-externals/issues/532
> >
> [rocketmq-flink] Checkstyle issues · Issue #532 ·
> apache/rocketmq-externals<
> https://github.com/apache/rocketmq-externals/issues/532>
> The issue tracker is ONLY used for bug report and feature request. Any
> question or RocketMQ proposal please use our mailing lists. BUG REPORT
> Please describe the issue you observed: What did you do...
> github.com
>
>
>
> Thank you and best regards,
> Nishadi
>
>
> Nishadi Kirielle
>
> PhD Student,
>
> Research School of Computer Science,
>
> ANU College of Engineering and Computer Science,
>
> Australian National University, Canberra, ACT 2601, Australia.
>
> 
> From: Nishadi Kirielle Arachchillage 
> Sent: Monday, March 9, 2020 9:34 PM
> To: heng du 
> Cc: nicholasji...@apache.org ;
> vongosl...@apache.org ; dev@rocketmq.apache.org <
> dev@rocketmq.apache.org>
> Subject: Re: [COMDEV-342] Flink Connect GSoC Project
>
> Thanks a lot, Henry. I am currently looking into the source code of the
> existing data stream connect of Flink.
> I will get back if any questions arise.
>
> Looking forward to contributing to the RocketMQ project...!!!
>
> Thank you and best regards,
> Nishadi
>
>
> Nishadi Kirielle
>
> PhD Student,
>
> Research School of Computer Science,
>
> ANU College of Engineering and Computer Science,
>
> Australian National University, Canberra, ACT 2601, Australia.
>
> 
> From: heng du 
> Sent: Monday, March 9, 2020 7:41 PM
> To: Nishadi Kirielle Arachchillage 
> Cc: nicholasji...@apache.org ;
> duhengfore...@apache.org ; vongosl...@apache.org
> ; dev@rocketmq.apache.org 
> Subject: Re: [COMDEV-342] Flink Connect GSoC Project
>
> Hi, Nishadi,
>
> Thanks for your attention to the Apache RocketMQ Connect Flink project<
> https:/