Request the Permission of ASF logos in Apache RocketMQ Meetup

[yukon]

Hi ASF Marketing & Publicity,

We will hold a meetup in Shenzhen, China at Dec. 16 pm., 2018, and want to
use some ASF logos in this activity:

1. https://www.apache.org/foundation/press/kit/asf_logo.emf
2. A POWERED BY logo, see the attachment.

These logos will be used on a poster, T-shirts, etc.

Requests the permission of these two logos.

Regards,
yukon


Apache_PoweredBy.ai
Description: application/illustrator

Re: Request the Permission of ASF logos in Apache RocketMQ Meetup

[yukon]

Got it, many thanks!

On Thu, Nov 30, 2017 at 11:58 AM, Sally Khudairi <s...@apache.org> wrote:

> Yes, of course. Here you go http://apache.org/foundation/marks/
>
> As always, feel free to let me know if you need anything :^)
>
> Warm regards,
> Sally
>
> - - -
> Vice President Marketing & Publicity
> The Apache Software Foundation
>
> Tel +1 617 921 8656 <+1%20617-921-8656>
> Skype sallykhudairi
>
>
> On Wed, Nov 29, 2017, at 22:54, yukon wrote:
>
> Hi Sally,
>
> ```
>  as that has a few more restrictions for its use as opposed to Apache
> project logos.
> ```
>
> One more thing, is there a doc to describe the restrictions?
>
> On Thu, Nov 30, 2017 at 11:30 AM, yukon <yu...@apache.org> wrote:
>
> Thanks, Sally!
>
> On Thu, Nov 30, 2017 at 10:37 AM, Sally Khudairi <s...@apache.org> wrote:
>
>
> Thanks, Yukon. Yes: that's fine.
>
> Have a great event!
>
> Kind regards,
> Sally
>
> - - -
> Vice President Marketing & Publicity
> The Apache Software Foundation
>
> Tel +1 617 921 8656 <+1%20617-921-8656>
> Skype sallykhudairi
>
>
> On Wed, Nov 29, 2017, at 21:17, yukon wrote:
>
> Hi Sally,
>
> The ASF logo will be used on a poster and T-shirts, the attached are a
> demo T-shirts. are these allowed?
>
> Regards,
> yukon
>
>
>
>
> On Thu, Nov 30, 2017 at 1:53 AM, Sally Khudairi <pr...@apache.org> wrote:
>
> Hello Yukon --thanks for your note.
>
> Yes, of course, we encourage all projects to create their own "Powered By
> Apache" logos using our template. So that's wonderful!
>
> I'll need to know the context for your use of the ASF logo, as that has a
> few more restrictions for its use as opposed to Apache project logos. If
> you can please let me know your intentions here, I'd greatly appreciate it.
>
> Many kind regards,
> Sally
>
>
> = = = = =
> vox +1 617 921 8656 <+1%20617-921-8656>
> gvox +1 646 598 4616 <+1%20646-598-4616>
> skype sallykhudairi
>
> --
> *From:* yukon <yu...@apache.org>
> *To:* ASF Marketing & Publicity <pr...@apache.org>
> *Cc:* dev@rocketmq.apache.org
> *Sent:* Wednesday, November 29, 2017 2:13 AM
> *Subject:* Request the Permission of ASF logos in Apache RocketMQ Meetup
>
> Hi ASF Marketing & Publicity,
>
> We will hold a meetup in Shenzhen, China at Dec. 16 pm., 2018, and want to
> use some ASF logos in this activity:
>
> 1. https://www.apache.org/foundation/press/kit/asf_logo.emf
> 2. A POWERED BY logo, see the attachment.
>
> These logos will be used on a poster, T-shirts, etc.
>
> Requests the permission of these two logos.
>
> Regards,
> yukon
>
> Email had 2 attachments:
>
>- 01.png
>  463k (image/png)
>- 03.png
>  476k (image/png)
>
>
>
>

[RESULT][VOTE]: Release Apache RocketMQ 4.2.0 RC1

[yukon]

Hello RocketMQ Community,

The Apache RocketMQ 4.2.0 vote is now closed and has passed with 3 binding
+1s, 2 non-binding +1s and no 0 or -1:

Binding votes +1s:

dongeforever
Von Gosling
yukon

Non-binding votes +1s:

Rovshen Nazarov
liuxue

The release will be published soon.

Thanks,
The Apache RocketMQ Team

On Fri, Dec 15, 2017 at 5:37 PM, liuxue <liuxue...@gmail.com> wrote:

> []+1
>
> On Thu, Dec 14, 2017 at 12:42 PM, yukon <yu...@apache.org> wrote:
>
> > HI Von,
> >
> > Thanks for your careful check. We will fix it int the next release and
> > submit a hotfix soon~
> >
> > Also, here is my +1 (binding).
> >
> > Sincerely request everybody review and vote on the RC1.
> >
> > Regards
> > yukon
> >
> > On Thu, Dec 14, 2017 at 11:33 AM, Von Gosling <vongosl...@apache.org>
> > wrote:
> >
> > > +1 (binding)
> > >
> > > Cool, I've successfully checked:
> > > * incubating name removed from final release
> > > * source releases file layouts
> > > * signatures and hashes good
> > > * matched git tags and commit ids
> > > * NOTICE and LICENSE files
> > > * license headers
> > > * clean build (Java 9.0.1_11, Darwin Kernel Version 17.3.0 x86_64)
> > >
> > >
> > > But I found a minor problem - one unexpected imported file 1, maybe, we
> > > made a mistake when merging some prs. IMO, we could fix it in the next
> > > release but hotfix before that coming :-)
> > >
> > > Best Regards,
> > > Von Gosling
> > >
> > > > 在 2017年12月13日，23:43，yukon <yu...@apache.org> 写道：
> > > >
> > > > Hello Apache RocketMQ Community,
> > > >
> > > > This is the vote for 4.2.0 of Apache RocketMQ. We now kindly request
> > the
> > > > RocketMQ community review and vote on this release artifact.
> > > >
> > > > Apache RocketMQ is a distributed messaging and streaming platform
> with
> > > low
> > > > latency, high performance and reliability, trillion-level capacity
> and
> > > > flexible scalability.
> > > >
> > > > The artifacts:
> > > > https://dist.apache.org/repos/dist/dev/rocketmq/4.2.0-rc1/
> > > >
> > > > The staging repo:
> > > > https://repository.apache.org/content/repositories/
> > > orgapacherocketmq-1007/
> > > >
> > > > Git tag for the release:
> > > > https://github.com/apache/rocketmq/tree/rocketmq-all-4.2.0
> > > >
> > > > Hash for the release tag:
> > > > 51d328e4e6fe1eae7073c5278c28de7dd059e016
> > > >
> > > > Release Notes:
> > > > https://rocketmq.apache.org/release_notes/release-notes-4.2.0/
> > > >
> > > > The artifacts have been signed with Key : E9BDDB0E, 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
> > >
> > >
> >
>

Re: What's DLQ?

[yukon]

Hi Frank Bian,

The DLQ means `Dead Letter Queue`, as you can see, all the messages will be
redirected to DLQ when these's  reconsumeTimes exceed
the maxReconsumeTimes(default is 16).

Each consumer group has a DLQ named `%DLQ%CID`, it's a special topic indeed
and doesn't have read permission by default.

In most cases, messages should be consumed successfully after 16 times
retry. if not, an application error may occurred, and should be resolved~

There is a related queue named `%RETRY%CID`, a special topic to queue the
retried messages.

Let me know if you have further questions.

Regards,
yukon

On Mon, Dec 18, 2017 at 3:00 PM, Frank Bian <frankb...@126.com> wrote:

> Hi guys,
>
> What is DLQ or DLQ topic ?
>
> I found that the msg will be queued by DLQ topic when the reconsumeTimes
> of it is bigger than maxReconsumeTimes , so the DLQ is special topic for
> this case?
>
>
>
> Best regards,
> Frank Bian
>
>

[ANNOUNCE] Release Apache RocketMQ 4.2.0

[yukon]

Hi all,

Apache RocketMQ is a distributed messaging and streaming platform with low
latency, high performance and reliability, trillion-level capacity and
flexible scalability.

The Apache RocketMQ community would like to announce the release of Apache
RocketMQ 4.2.0.

This release supports some new features:

1. Support transportation layer security
2. Support log4j2 in client
3. Support more flexible flow control mechanism in client

Also, fixed some known bugs and some performance issues.
More details regarding Apache RocketMQ 4.2.0 can be found at:
https://rocketmq.apache.org/

The release artifacts can be downloaded here:
https://dist.apache.org/repos/dist/release/rocketmq/4.2.0

The release notes can be found here:
https://rocketmq.apache.org/release_notes/release-notes-4.2.0/

Thanks,
The Apache RocketMQ Team

Re: About version 4.2.0

[yukon]

Hi Martin,

The download link for 4.2.0 has been added to rocketmq website, please
check it.

Regards,
yukon

On Mon, Dec 18, 2017 at 2:35 PM, yukon <yu...@apache.org> wrote:

> Hi Martin,
>
> 4.2.0 has been released just now, the download link will be updated soon~
>
> Regards,
> yukon
>
> On Mon, Dec 18, 2017 at 12:24 PM, Martin <ghx02...@126.com> wrote:
>
>> Hi guys,
>>
>> I am seeing the release notes of version 4.2.0 have been published.
>> but seems there is no download link for version 4.2.0. the only way i can
>> get 4.2.0 is from github sourcode.
>> Does this means version 4.2.0 is not a standard release or version 4.2.0
>> is not recommended to use?
>>
>>
>> thanks,
>> Martin
>>
>>
>>
>>
>
>

Re: [VOTE]: Release Apache RocketMQ 4.2.0 RC1

[yukon]

HI Von,

Thanks for your careful check. We will fix it int the next release and
submit a hotfix soon~

Also, here is my +1 (binding).

Sincerely request everybody review and vote on the RC1.

Regards
yukon

On Thu, Dec 14, 2017 at 11:33 AM, Von Gosling <vongosl...@apache.org> wrote:

> +1 (binding)
>
> Cool, I've successfully checked:
> * incubating name removed from final release
> * source releases file layouts
> * signatures and hashes good
> * matched git tags and commit ids
> * NOTICE and LICENSE files
> * license headers
> * clean build (Java 9.0.1_11, Darwin Kernel Version 17.3.0 x86_64)
>
>
> But I found a minor problem - one unexpected imported file 1, maybe, we
> made a mistake when merging some prs. IMO, we could fix it in the next
> release but hotfix before that coming :-)
>
> Best Regards,
> Von Gosling
>
> > 在 2017年12月13日，23:43，yukon <yu...@apache.org> 写道：
> >
> > Hello Apache RocketMQ Community,
> >
> > This is the vote for 4.2.0 of Apache RocketMQ. We now kindly request the
> > RocketMQ community review and vote on this release artifact.
> >
> > Apache RocketMQ is a distributed messaging and streaming platform with
> low
> > latency, high performance and reliability, trillion-level capacity and
> > flexible scalability.
> >
> > The artifacts:
> > https://dist.apache.org/repos/dist/dev/rocketmq/4.2.0-rc1/
> >
> > The staging repo:
> > https://repository.apache.org/content/repositories/
> orgapacherocketmq-1007/
> >
> > Git tag for the release:
> > https://github.com/apache/rocketmq/tree/rocketmq-all-4.2.0
> >
> > Hash for the release tag:
> > 51d328e4e6fe1eae7073c5278c28de7dd059e016
> >
> > Release Notes:
> > https://rocketmq.apache.org/release_notes/release-notes-4.2.0/
> >
> > The artifacts have been signed with Key : E9BDDB0E, 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
>
>

[VOTE]: Release Apache RocketMQ 4.2.0 RC1

[yukon]

Hello Apache RocketMQ Community,

This is the vote for 4.2.0 of Apache RocketMQ. We now kindly request the
RocketMQ community review and vote on this release artifact.

Apache RocketMQ is a distributed messaging and streaming platform with low
latency, high performance and reliability, trillion-level capacity and
flexible scalability.

The artifacts:
https://dist.apache.org/repos/dist/dev/rocketmq/4.2.0-rc1/

The staging repo:
https://repository.apache.org/content/repositories/orgapacherocketmq-1007/

Git tag for the release:
https://github.com/apache/rocketmq/tree/rocketmq-all-4.2.0

Hash for the release tag:
51d328e4e6fe1eae7073c5278c28de7dd059e016

Release Notes:
https://rocketmq.apache.org/release_notes/release-notes-4.2.0/

The artifacts have been signed with Key : E9BDDB0E, 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

Re: [ANNOUNCE] Release Apache RocketMQ 4.2.0

[yukon]

Hi sebb and justin, thanks to your suggestion.

I have polished our quick start doc and provided simple steps to build
from official Apache release.

Also, we will use the mirror site link in our next release announcement.

Regards,
yukon

On Tue, Dec 19, 2017 at 10:57 AM, Von Gosling <vongosl...@apache.org> wrote:

> Thanks sebb and justin suggestion. I have looked at some other Apache
> TLPs, including justin’s link[1]. We will consider to polish quick-start
> guide using ASF proved release :-)
>
>
> [1] http://www.apache.org/legal/release-policy.html#host-rc <
> http://www.apache.org/legal/release-policy.html#host-rc>
>
>
> Best Regards,
> Von Gosling
>
> > 在 2017年12月19日，08:06，sebb <seb...@gmail.com> 写道：
> >
> > On 18 December 2017 at 23:13, Justin Mclean <jus...@classsoftware.com>
> wrote:
> >> Hi,
> >>
> >> Also, the quickstart page
> >> https://rocketmq.apache.org/docs/quick-start/
> >> says  to clone the development branch of the code.
> >>
> >> Only source that has been formally approved by the PMC should be
> advertised.
> >>
> >>
> >> I’m not sure that applies to source code just to unproved releases.
> i.e. you
> >
> > Source code is the primary output of ASF projects.
> >
> >> can’t post links to unproved releases like nightly builds and the like
> [1]
> >> (and even some projects do this) e.g. [3] but make it clear it’s not an
> >> official build. Many top level projects I’ve looked at include links to
> the
> >> work in progress repo and some projects have no distinction between
> master
> >> and develop.
> >
> > That does not make it right.
> > It also depends which part of the website has the links.
> > It's OK to link to the repo from pages intended for developers, but
> > not from pages intended for the general public.
> >
> >> Perhaps just change that page and suggest that people use the download
> page
> >> [2] to get an official release above where that the repo information is
> >> listed and note that the develop branch may contain code that is not in
> an
> >> official release?
> >>
> >> Thanks,
> >> Justin
> >>
> >> 1. http://www.apache.org/legal/release-policy.html#host-rc
> >> 2. https://rocketmq.apache.org/dowloading/releases/
> >> 3. https://ant.apache.org/nightlies.html
>
>

Re: [ANNOUNCE] Congrats, CSoC Start !

[yukon]

Hi Guys,

Congratulations on getting these GSoC projects, though that it's too late.

Looking forward to working with you guys this summer.

```
I would like to ask why Yukon isn't listed in the mentors list assigned to
my project?
```

I am, but the listed name is `Xinyu Zhou` which is my full name, while
`Yukon` is my nickname, sorry for the confusion.

```
My sincere thanks to Yukon too for reviewing my proposal before apply.
```

It's my pleasure.

Regards,
yukon

On Thu, Apr 26, 2018 at 4:42 PM, Von Gosling <vongosl...@apache.org> wrote:

> Hi,
>
> GSoC guys, have you subscribed our dev and user email list, I have
> received some unauthorized mails from your addresses.
>
> Best Regards,
> Von Gosling
>
> 在 2018年4月24日，10:21，Von Gosling <vongosl...@apache.org> 写道：
>
> I am pleased to announce our 3 topics are selected by GSoC Mentor
> Groups[1]. I am also pleasure to mentor our students Sergio Esteves and
> Kasthuriraajan, our pmc member yukon will also help Mayar Mahmoud to finish
> the openwhisk integration. Let’s complete the topics with close teamwork.
> Any guys who want to join the topics, welcome discussion in the dev email
> list:-)
>
>
>

Re: [DISCUSS] Migrate JIRA to Github Issue

[yukon]

Hi all,

Please note that we cannot migrate any existing Jira tickets to Github
Issues. We need to start fresh and migrate the incomplete tickets to
Github manually.

I will open a migrate ticket to INFRA next week if there is no opposite
voice.

Regards,
yukon

On Fri, Jan 5, 2018 at 5:39 PM, Xin Wang <data.xinw...@gmail.com> wrote:

> +1 for moving issues to github due to the bad network.
> Besides we still need handle issues from Jira carefully; indeed active
> community is one of the most important things.
>
> Thanks,
> Xin
>
> 2018-01-04 11:47 GMT+08:00 dongeforever <dongefore...@apache.org>:
>
> > +1
> >
> > The JIRA system is truly slow in China, which makes it difficult to
> create
> > or update an ISSUE.
> > It would be great to migrate the issues to github.
> >
> >
> > Best Regards
> > dongeforever
> >
> >
> > 2018-01-02 21:24 GMT+08:00 yukon <yu...@apache.org>:
> >
> > > Hi Justin,
> > >
> > > RocketMQ is hosted on Gitbox now, and every software engineer has a
> > proper
> > > way to reach GitHub, no need to worry about it :)
> > >
> > > Regards,
> > > yukon
> > >
> > > On Tue, Jan 2, 2018 at 8:22 PM, Justin Mclean <
> jus...@classsoftware.com>
> > > wrote:
> > >
> > > > Hi,
> > > >
> > > > > Consider that most of users and contributors are from China while
> the
> > > > JIRA system has a slow response for us, so I propose that RocketMQ
> > should
> > > > migrate from JIRA to Github issue for working efficiency.
> > > > >
> > > > > Furthermore, the Github issue has a better integration with pull
> > > > requests, could speed up the merge process.
> > > >
> > > > Other Apache projects do the so it’s certainly possible. I’m not from
> > > > China so forgive my ignorance on this matter but is there a concern
> > that
> > > > GitHub could be possibly blocked? I seem to remember it being blocked
> > > for a
> > > > time in 2016. Using Apache gitbox service [1] may get around that??
> > > >
> > > > Thank,
> > > > Justin
> > > >
> > > > 1.  https://gitbox.apache.org
> > > >
> > > >
> > >
> >
>
>
>
> --
> Thanks,
> Xin
>

IP clearance progress of RocketMQ CPP SDK donation

[yukon]

Hi qiwei,

Thanks again for your donation RocketMQ CPP SDK, kindly please help us
clear the related IP issues.

As we already have a discussion on  this issue:

https://lists.apache.org/thread.html/7acdd3604355aaab9df027da32205c2228885ed6b40143101014a825@%3Cdev.rocketmq.apache.org%3E

I created a JIRA issue to track this task:

https://issues.apache.org/jira/browse/ROCKETMQ-352

Please qiwei  provide the bellow files for us:

* Fill the SGA file[1] and send it to secret...@apache.org:
* The donated source code zip and the SHA-1 value.

After that, we will create the status page and call a vote in Apache
RocketMQ community.

[1]. https://www.apache.org/licenses/software-grant-template.pdf

Regards,
yukon

Re: The State of RocketMQ Streaming Integration

[yukon]

Cool, thanks for your outstanding contribution, to help RocketMQ community
integrate with other streaming platforms.

On Fri, Jan 19, 2018 at 7:52 PM, Xin Wang  wrote:

> Hi devs,
>
> I have finished the improvements for integrating RocketMQ with Apache
> Storm.
> Main changes are as following:
>
>- Upgraded RocketMQ version to 4.2.0 which brings improvements and new
>features like batch sending
>- Imporved retry policy for RocketMQ consumer push mode to avoid data
>loss in some scenes
>- Batch sending supported for bolt and trident state
>- Allow running several consumer instances in one process, that is to
>say, different topics in one worker is possible
>
> PR: https://github.com/apache/storm/pull/2518
>
> And I submit the `RocketMQ-Serializer` patch several days ago. This module
> includes several serialization formats, especially Apache Avro which I
> stated before[1].
>
>- Raw String
>- JSON
>- Avro Generic
>- Avro Specified
>
> PR: https://github.com/apache/rocketmq-externals/pull/42
>
> Any comments for these PRs are welcome. BTW here is the state of rocketmq
> streaming integration:
>ModuleStatus
> * RocketMQ-StormPatch Available
> * RocketMQ-SparkTo Refactor
> * RocketMQ-Flink Patch Available Soon
> * RocketMQ-Serializer Patch Available
>
> Anybody who is also interested in these tasks, please join me. Let's fight
> together.
>
>
> [1] https://issues.apache.org/jira/browse/ROCKETMQ-157
>
>
> Thanks,
>
> Xin Wang (vesense)
>

Re: IP clearance progress of RocketMQ CPP SDK donation

[yukon]

Hi all,

We should speed up the IP clearance process. We will call the vote in dev
soon if our PMC have no other opinion.

Regards,
yukon

On Sat, Jan 13, 2018 at 1:12 AM, Von Gosling <vongosl...@apache.org> wrote:

> Hi qiwei,
>
>
> > Also I don’t think there is any reason to copy private@ on this
> subject. This can be discussed on dev@.
>
> I guess this is the reason that I received your request to subscribe
> rocketmq private email list more times, I am also agreed to not to cc to
> private address :-).
>
> Best Regards,
> Von Gosling
>
> > 在 2018年1月12日，17:06，Justin Mclean <jus...@classsoftware.com> 写道：
> >
> > Hi,
> >
> > Also I don’t think there is any reason to copy private@ on this
> subject. This can be discussed on dev@.
> >
> > Thanks,
> > Justin
>
>

Re: IP clearance progress of RocketMQ CPP SDK donation

[yukon]

Hi, all

The donated software has three source dependencies:

1. Disruptor CPP version: https://github.com/fsaintjacques/disruptor--

Its copyright looks are compatible with ASF projects:

// Copyright (c) 2011-2015, Francois Saint-Jacques
// All rights reserved.
//
// Redistribution and use in source and binary forms, with or without
// modification, are permitted provided that the following conditions are
met:
// * Redistributions of source code must retain the above copyright
//   notice, this list of conditions and the following disclaimer.
// * Redistributions in binary form must reproduce the above copyright
//   notice, this list of conditions and the following disclaimer in the
//   documentation and/or other materials provided with the
distribution.
// * Neither the name of the disruptor-- nor the
//   names of its contributors may be used to endorse or promote
products
//   derived from this software without specific prior written
permission.
//
// THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS "AS
IS"
// AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
// IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR
PURPOSE
// ARE DISCLAIMED. IN NO EVENT SHALL FRANCOIS SAINT-JACQUES BE LIABLE FOR
ANY
// DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL
DAMAGES
// (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR
SERVICES;
// LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED
AND
// ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR
TORT
// (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF
// THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.


2. src/common/FastDelegate.h, which has been donated to CodeProject, and is
under CPOL: https://www.codeproject.com/info/cpol10.aspx

But CPOL isn't compatible with ASF, see:
https://www.apache.org/legal/resolved#category-x

```
Due to restrictions (see 5.d and 5.f), falls short of the Open Source
Definition, thereby violating the first criterion for license approval.
```

Please qiwei help us resolve this issue.


3. big_endian.cpp is derived from the Google Chrome, which is under BSD
license and compatible with ASF: https://www.chromium.org/


Regards,
yukon


On Wed, Jan 10, 2018 at 11:07 PM, yukon <yu...@apache.org> wrote:

> Hi,
>
> Thanks
>
> I attached the donated software to issue https://issues.apache.
> org/jira/browse/ROCKETMQ-352.
>
> Regards,
> yukon
>
> On Wed, Jan 10, 2018 at 9:00 PM, 王启伟(孝孺) <qiwei@alibaba-inc.com>
> wrote:
>
>> Hi,
>>
>> Attachement is the donated source code zip, and the SHA-1 value is:
>> c39dda2989fd09acabb9f83a56ed6fa5cb126818.
>> I will fill the SGA file and send later, Thanks.
>>
>> --
>> 发件人：yukon <yu...@apache.org>
>> 发送时间：2018年1月10日(星期三) 17:43
>> 收件人：王启伟(孝孺) <qiwei@alibaba-inc.com>; dev <dev@rocketmq.apache.org>
>> 抄 送：private <priv...@rocketmq.apache.org>
>> 主 题：IP clearance progress of RocketMQ CPP SDK donation
>>
>> Hi qiwei,
>>
>> Thanks again for your donation RocketMQ CPP SDK, kindly please help us
>> clear the related IP issues.
>>
>> As we already have a discussion on  this issue:
>>
>> https://lists.apache.org/thread.html/7acdd3604355aaab9df027d
>> a32205c2228885ed6b40143101014a825@%3Cdev.rocketmq.apache.org%3E
>>
>> I created a JIRA issue to track this task:
>>
>> https://issues.apache.org/jira/browse/ROCKETMQ-352
>>
>> Please qiwei  provide the bellow files for us:
>>
>> * Fill the SGA file[1] and send it to secret...@apache.org:
>> * The donated source code zip and the SHA-1 value.
>>
>> After that, we will create the status page and call a vote in Apache
>> RocketMQ community.
>>
>> [1]. https://www.apache.org/licenses/software-grant-template.pdf
>>
>> Regards,
>> yukon
>>
>>
>>
>

Re: IP clearance progress of RocketMQ CPP SDK donation

[yukon]

And kindly please contributors, committers, and PMC members help us check
this code base, see: https://issues.apache.org/jira/browse/ROCKETMQ-352

On Fri, Jan 12, 2018 at 3:02 PM, yukon <yu...@apache.org> wrote:

> Hi, all
>
> The donated software has three source dependencies:
>
> 1. Disruptor CPP version: https://github.com/fsaintjacques/disruptor--
>
> Its copyright looks are compatible with ASF projects:
>
> // Copyright (c) 2011-2015, Francois Saint-Jacques
> // All rights reserved.
> //
> // Redistribution and use in source and binary forms, with or without
> // modification, are permitted provided that the following conditions are
> met:
> // * Redistributions of source code must retain the above copyright
> //   notice, this list of conditions and the following disclaimer.
> // * Redistributions in binary form must reproduce the above copyright
> //   notice, this list of conditions and the following disclaimer in
> the
> //   documentation and/or other materials provided with the
> distribution.
> // * Neither the name of the disruptor-- nor the
> //   names of its contributors may be used to endorse or promote
> products
> //   derived from this software without specific prior written
> permission.
> //
> // THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS "AS
> IS"
> // AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO,
> THE
> // IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR
> PURPOSE
> // ARE DISCLAIMED. IN NO EVENT SHALL FRANCOIS SAINT-JACQUES BE LIABLE FOR
> ANY
> // DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL
> DAMAGES
> // (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR
> SERVICES;
> // LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED
> AND
> // ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR
> TORT
> // (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF
> // THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
>
>
> 2. src/common/FastDelegate.h, which has been donated to CodeProject, and
> is under CPOL: https://www.codeproject.com/info/cpol10.aspx
>
> But CPOL isn't compatible with ASF, see: https://www.apache.org/
> legal/resolved#category-x
>
> ```
> Due to restrictions (see 5.d and 5.f), falls short of the Open Source
> Definition, thereby violating the first criterion for license approval.
> ```
>
> Please qiwei help us resolve this issue.
>
>
> 3. big_endian.cpp is derived from the Google Chrome, which is under BSD
> license and compatible with ASF: https://www.chromium.org/
>
>
> Regards,
> yukon
>
>
> On Wed, Jan 10, 2018 at 11:07 PM, yukon <yu...@apache.org> wrote:
>
>> Hi,
>>
>> Thanks
>>
>> I attached the donated software to issue https://issues.apache.or
>> g/jira/browse/ROCKETMQ-352.
>>
>> Regards,
>> yukon
>>
>> On Wed, Jan 10, 2018 at 9:00 PM, 王启伟(孝孺) <qiwei....@alibaba-inc.com>
>> wrote:
>>
>>> Hi,
>>>
>>> Attachement is the donated source code zip, and the SHA-1 value is:
>>> c39dda2989fd09acabb9f83a56ed6fa5cb126818.
>>> I will fill the SGA file and send later, Thanks.
>>>
>>> --
>>> 发件人：yukon <yu...@apache.org>
>>> 发送时间：2018年1月10日(星期三) 17:43
>>> 收件人：王启伟(孝孺) <qiwei@alibaba-inc.com>; dev <dev@rocketmq.apache.org>
>>> 抄 送：private <priv...@rocketmq.apache.org>
>>> 主 题：IP clearance progress of RocketMQ CPP SDK donation
>>>
>>> Hi qiwei,
>>>
>>> Thanks again for your donation RocketMQ CPP SDK, kindly please help us
>>> clear the related IP issues.
>>>
>>> As we already have a discussion on  this issue:
>>>
>>> https://lists.apache.org/thread.html/7acdd3604355aaab9df027d
>>> a32205c2228885ed6b40143101014a825@%3Cdev.rocketmq.apache.org%3E
>>>
>>> I created a JIRA issue to track this task:
>>>
>>> https://issues.apache.org/jira/browse/ROCKETMQ-352
>>>
>>> Please qiwei  provide the bellow files for us:
>>>
>>> * Fill the SGA file[1] and send it to secret...@apache.org:
>>> * The donated source code zip and the SHA-1 value.
>>>
>>> After that, we will create the status page and call a vote in Apache
>>> RocketMQ community.
>>>
>>> [1]. https://www.apache.org/licenses/software-grant-template.pdf
>>>
>>> Regards,
>>> yukon
>>>
>>>
>>>
>>
>

Re: IP clearance progress of RocketMQ CPP SDK donation

[yukon]

Thanks, qiwei.

The code base has been updated in our track issue:
https://issues.apache.org/jira/browse/ROCKETMQ-352

On Fri, Jan 12, 2018 at 4:55 PM, 王启伟(孝孺) <qiwei@alibaba-inc.com> wrote:

> Hi all,
>
> After delete "src/common/FastDelegate.h" which is CPOL license, I update
> the source code zip(shasum:c3553dbe3c1524fe4afb3a619e2c7acfdf9eefed) in
> attachment, please review it, thanks.
>
> --
> 发件人：王启伟(孝孺) <qiwei@alibaba-inc.com>
> 发送时间：2018年1月12日(星期五) 15:10
> 收件人：yukon <yu...@apache.org>
> 抄 送：dev <dev@rocketmq.apache.org>; private <priv...@rocketmq.apache.org>
> 主 题：回复：IP clearance progress of RocketMQ CPP SDK donation
>
> Hi yukon,
>
> Thanks your remind.
> I just checked that  "src/common/FastDelegate.h" is not used anymore,  I
> will delete it from source code.
>
> ```
> 2. src/common/FastDelegate.h, which has been donated to CodeProject, and
> is under CPOL: https://www.codeproject.com/info/cpol10.aspx
>
> But CPOL isn't compatible with ASF, see: https://www.apache.org/
> legal/resolved#category-x
> ```
>
> --
> 发件人：yukon <yu...@apache.org>
> 发送时间：2018年1月12日(星期五) 15:04
> 收件人：王启伟(孝孺) <qiwei@alibaba-inc.com>
> 抄 送：dev <dev@rocketmq.apache.org>; private <priv...@rocketmq.apache.org>
> 主 题：Re: IP clearance progress of RocketMQ CPP SDK donation
>
> And kindly please contributors, committers, and PMC members help us check
> this code base, see: https://issues.apache.org/jira/browse/ROCKETMQ-352
>
> On Fri, Jan 12, 2018 at 3:02 PM, yukon <yu...@apache.org> wrote:
> Hi, all
>
> The donated software has three source dependencies:
>
> 1. Disruptor CPP version: https://github.com/fsaintjacques/disruptor--
>
> Its copyright looks are compatible with ASF projects:
>
> // Copyright (c) 2011-2015, Francois Saint-Jacques
> // All rights reserved.
> //
> // Redistribution and use in source and binary forms, with or without
> // modification, are permitted provided that the following conditions are
> met:
> // * Redistributions of source code must retain the above copyright
> //   notice, this list of conditions and the following disclaimer.
> // * Redistributions in binary form must reproduce the above copyright
> //   notice, this list of conditions and the following disclaimer in
> the
> //   documentation and/or other materials provided with the
> distribution.
> // * Neither the name of the disruptor-- nor the
> //   names of its contributors may be used to endorse or promote
> products
> //   derived from this software without specific prior written
> permission.
> //
> // THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS "AS
> IS"
> // AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO,
> THE
> // IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR
> PURPOSE
> // ARE DISCLAIMED. IN NO EVENT SHALL FRANCOIS SAINT-JACQUES BE LIABLE FOR
> ANY
> // DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL
> DAMAGES
> // (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR
> SERVICES;
> // LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED
> AND
> // ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR
> TORT
> // (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF
> // THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
>
>
> 2. src/common/FastDelegate.h, which has been donated to CodeProject, and
> is under CPOL: https://www.codeproject.com/info/cpol10.aspx
>
> But CPOL isn't compatible with ASF, see: https://www.apache.org/
> legal/resolved#category-x
>
> ```
> Due to restrictions (see 5.d and 5.f), falls short of the Open Source
> Definition, thereby violating the first criterion for license approval.
> ```
>
> Please qiwei help us resolve this issue.
>
>
> 3. big_endian.cpp is derived from the Google Chrome, which is under BSD
> license and compatible with ASF: https://www.chromium.org/
>
>
> Regards,
> yukon
>
>
> On Wed, Jan 10, 2018 at 11:07 PM, yukon <yu...@apache.org> wrote:
> Hi,
>
> Thanks
>
> I attached the donated software to issue https://issues.apache.
> org/jira/browse/ROCKETMQ-352.
>
> Regards,
> yukon
>
> On Wed, Jan 10, 2018 at 9:00 PM, 王启伟(孝孺) <qiwei@alibaba-inc.com>
> wrote:
> Hi,
>
> Attachement is the donated source code zip, and the SHA-1 value is:
> c39dda2989fd09acabb9f83a56ed6fa5cb126818.
> I wi

Re: [CLOSE][VOTE] Accept RocketMQ CPP SDK Code Donation

[yukon]

I am sorry to close the vote, because of the error text. I will open a new
vote soon~

On Mon, Feb 5, 2018 at 7:27 PM, Von Gosling <vongosl...@apache.org> wrote:

> +1
>
> Looking forward to our continuous endeavour for cpp client :-)
>
> Best Regards,
> Von Gosling
>
> > 在 2018年2月5日，16:04，yukon <yu...@apache.org> 写道：
> >
> > The process is tracked under ROCKETMQ-352 and the source code is
> available
>
>

[VOTE] Accept RocketMQ CPP SDK Code Donation

[yukon]

Hi all,

Following an earlier discussion thread, I’d like to start of VOTE on
whether to accept the RocketMQ CPP SDK donation from Qiwei Wang.

RocketMQ CPP SDK is a stable, widely used C++ client SDK of Apache
RocketMQ, for Linux and Windows platform. It supports full features of
RocketMQ Java client and has played an important role in many distributed
applications of Alibaba Group.

The process is tracked under ROCKETMQ-352 and the source code is available
here:

https://issues.apache.org/jira/secure/attachment/12905462/rocketmq-cpp.zip
sha1: c3553dbe3c1524fe4afb3a619e2c7acfdf9eefed

The IP Clearance document:
http://incubator.apache.org/ip-clearance/rocketmq-cpp-sdk.html

Please vote to approve this contribution.  Lazy consensus applies: if no -1
votes are cast within the next 72 hours, the vote passes.

[ ] +1 Accept RocketMQ CPP SDK into Apache RocketMQ
[ ] -1 Reject the contribution because...

Regards,
yukon

[VOTE] Accept RocketMQ CPP SDK Code Donation

[yukon]

Hi all,

Following an earlier discussion thread, I’d like to start of VOTE on
whether to accept the RocketMQ CPP SDK donation from Qiwei Wang.

RocketMQ CPP SDK is a stable, widely used C++ client SDK of Apache
RocketMQ, for Linux and Windows platform. It supports full features of
RocketMQ Java client and has played an important role in many distributed
applications of Alibaba Group.

The process is tracked under ROCKETMQ-352 and the source code is available
here:

https://issues.apache.org/jira/secure/attachment/12905462/rocketmq-cpp.zip
sha1: c3553dbe3c1524fe4afb3a619e2c7acfdf9eefed

The IP Clearance document:
http://incubator.apache.org/ip-clearance/rocketmq-cpp-sdk.html

Please vote to approve this contribution.  Lazy consensus applies: if no -1
votes are cast

within the next 72 hours, the vote passes.

[ ] +1 Accept FileVault into Apache Jackrabbit
[ ] -1 Reject the contribution because...

Regards,
yukon

Re: The source code on master branch can't pass unit test

[yukon]

I have updated the test certs
please try again

KaiYuan Yang 于2018年2月12日 周一下午5:24写道：

> How to reproduce the error:just run "mvn clean install -DskipITs" on
> the latest code
> Error
> message:org.apache.rocketmq.remoting.exception.RemotingSendRequestException: 
> send request to  127.0.0.1:> failed
>
>
>  at 
> org.apache.rocketmq.remoting.netty.NettyRemotingAbstract.invokeSyncImpl(NettyRemotingAbstract.java:389)
>
>  at 
> org.apache.rocketmq.remoting.netty.NettyRemotingClient.invokeSync(NettyRemotingClient.java:369)
>
>  at 
> org.apache.rocketmq.remoting.TlsTest.requestThenAssertResponse(TlsTest.java:292)
>
>  at 
> org.apache.rocketmq.remoting.TlsTest.serverAcceptsUntrustedClientCert(TlsTest.java:198)
>  at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>
>  at 
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
>
>  at 
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>  at java.lang.reflect.Method.invoke(Method.java:498)
>
>  at 
> org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:47)
>
>  at 
> org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
>
>  at 
> org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:44)
>
>  at 
> org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17)
>
>  at 
> org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:26)
>
>  at 
> org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:27)
>  at org.junit.rules.TestWatcher$1.evaluate(TestWatcher.java:55)
>  at org.junit.rules.ExternalResource$1.evaluate(ExternalResource.java:48)
>  at org.junit.rules.RunRules.evaluate(RunRules.java:20)
>  at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:271)
>
>  at 
> org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:70)
>
>  at 
> org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:50)
>  at org.junit.runners.ParentRunner$3.run(ParentRunner.java:238)
>  at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:63)
>  at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:236)
>  at org.junit.runners.ParentRunner.access$000(ParentRunner.java:53)
>  at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:229)
>  at org.junit.runners.ParentRunner.run(ParentRunner.java:309)
>
>  at 
> org.mockito.internal.runners.DefaultInternalRunner$1.run(DefaultInternalRunner.java:68)
>
>  at 
> org.mockito.internal.runners.DefaultInternalRunner.run(DefaultInternalRunner.java:74)
>  at org.mockito.internal.runners.StrictRunner.run(StrictRunner.java:39)
>  at org.mockito.junit.MockitoJUnitRunner.run(MockitoJUnitRunner.java:142)
>  at org.junit.runner.JUnitCore.run(JUnitCore.java:160)
>
>  at 
> com.intellij.junit4.JUnit4IdeaTestRunner.startRunnerWithArgs(JUnit4IdeaTestRunner.java:68)
>
>  at 
> com.intellij.rt.execution.junit.IdeaTestRunner$Repeater.startRunnerWithArgs(IdeaTestRunner.java:47)
>
>  at 
> com.intellij.rt.execution.junit.JUnitStarter.prepareStreamsAndStart(JUnitStarter.java:242)
>  at com.intellij.rt.execution.junit.JUnitStarter.main(JUnitStarter.java:70)
> Caused by: javax.net.ssl.SSLHandshakeException: General SSLEngine problem
>  at sun.security.ssl.Handshaker.checkThrown(Handshaker.java:1478)
>  at sun.security.ssl.SSLEngineImpl.checkTaskThrown(SSLEngineImpl.java:535)
>  at sun.security.ssl.SSLEngineImpl.readNetRecord(SSLEngineImpl.java:813)
>  at sun.security.ssl.SSLEngineImpl.unwrap(SSLEngineImpl.java:781)
>  at javax.net.ssl.SSLEngine.unwrap(SSLEngine.java:624)
>  at io.netty.handler.ssl.SslHandler.unwrap(SslHandler.java:1097)
>  at io.netty.handler.ssl.SslHandler.unwrap(SslHandler.java:968)
>  at io.netty.handler.ssl.SslHandler.decode(SslHandler.java:902)
>
>  at 
> io.netty.handler.codec.ByteToMessageDecoder.callDecode(ByteToMessageDecoder.java:411)
>
>  at 
> io.netty.handler.codec.ByteToMessageDecoder.channelRead(ByteToMessageDecoder.java:248)
>
>  at 
> io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:367)
>
>  at 
> io.netty.channel.AbstractChannelHandlerContext.access$600(AbstractChannelHandlerContext.java:36)
>
>  at 
> io.netty.channel.AbstractChannelHandlerContext$7.run(AbstractChannelHandlerContext.java:358)
>
>  at 
> io.netty.util.concurrent.DefaultEventExecutor.run(DefaultEventExecutor.java:41)
>
>  at 
> io.netty.util.concurrent.SingleThreadEventExecutor$2.run(SingleThreadEventExecutor.java:140)
>  at java.lang.Thread.run(Thread.java:748)
> Caused by: javax.net.ssl.SSLHandshakeException: General SSLEngine problem
>  at sun.security.ssl.Alerts.getSSLException(Alerts.java:192)
>  at sun.security.ssl.SSLEngineImpl.fatal(SSLEngineImpl.java:1728)
>  at sun.security.ssl.Handshaker.fatalSE(Handshaker.java:304)
>  at 

Re: [DISCUSS] Migrate JIRA to Github Issue

[yukon]

Hi Justin,

That makes sense, +dev list.

Please let us know if anyone is in trouble when submitting a report to JIRA
system.

On Tue, Jan 2, 2018 at 7:59 PM, Justin Mclean 
wrote:

> Hi,
>
> IMO it would be better to discuss this on dev list as I think as it
> impacts all committers and potential committers not just PMC members.
>
> Thanks,
> Justin

Re: [DISCUSS] Migrate JIRA to Github Issue

[yukon]

Hi Justin,

RocketMQ is hosted on Gitbox now, and every software engineer has a proper
way to reach GitHub, no need to worry about it :)

Regards,
yukon

On Tue, Jan 2, 2018 at 8:22 PM, Justin Mclean <jus...@classsoftware.com>
wrote:

> Hi,
>
> > Consider that most of users and contributors are from China while the
> JIRA system has a slow response for us, so I propose that RocketMQ should
> migrate from JIRA to Github issue for working efficiency.
> >
> > Furthermore, the Github issue has a better integration with pull
> requests, could speed up the merge process.
>
> Other Apache projects do the so it’s certainly possible. I’m not from
> China so forgive my ignorance on this matter but is there a concern that
> GitHub could be possibly blocked? I seem to remember it being blocked for a
> time in 2016. Using Apache gitbox service [1] may get around that??
>
> Thank,
> Justin
>
> 1.  https://gitbox.apache.org
>
>

Re: [DISCUSS] How to handle Ip-clearance for apache rocketmq community projects

[yukon]

Hi,

Add vincentWangKB to the recipient list.

vincentWangKB announced the contribution of the rocketmq-cpp project in our
community lately[1], It's undoubtedly true that this project should pass
through the IP clearance.

Consider that our PMC has no experience to help outside project through the
IP clearance, I suggest let's start the process with this case, clear the
IP issues on the rocketmq-cpp project ASAP.

Hope we could resolve this issue before submitting next board report :)

[1].
https://lists.apache.org/thread.html/7de2547f2eb29aede24d220628aad2ce8d1aaf8b21d118ec9b72bacd@%3Cdev.rocketmq.apache.org%3E
[2]. http://incubator.apache.org/ip-clearance/

Regards,
yukon

On Tue, Jan 2, 2018 at 7:23 PM, vongosling <fengji...@gmail.com> wrote:

> Sorry to miss the context. Repost again :-)
>
> Hi,
>
> As the topic said, I would like to put forward this issue despite we are
> apache tlp project. Firstly. we must arrange the total projects outside of
> Apache Repository[3]. According to my work on Apache RocketMQ Externals,
> CPP client[1] is a contribution from Alibaba, which is outside of Apache
> Repository. Could anyone add else? If no, I suggest we re-check what we
> have done about all external projects [2].
>
>
>
> [1] https://github.com/apache/rocketmq-externals/tree/master/rocketmq-cpp
> [2] https://github.com/apache/rocketmq-externals
> [3] http://incubator.apache.org/ip-clearance/
>
>
> Best Regards,
> Von Gosling
>
>
> 2017-03-20 17:04 GMT+08:00 Von Gosling <vongosl...@apache.org>:
>
> > Hi,
> >
> > >  Perhaps like Justin
> > > said above, getting ICLAs from the contributors and having the
> potential
> > > committer discussion about each of them right away.
> >
> >
> >
> > Actually, i was also puzzled about this contribution behavior coming from
> > some Apache Project Community. I have been investing other Apache TLP
> works
> > about here. They get them involved in through the same git repository, or
> > leave them alone, just through one formal link to touch these community
> > projects. But as for us, we hope to merge the mature project to our
> > repository, let it under Apache RocketMQ’s umbrella. So, that’s why we
> > provided the Github group RocketMQ firstly, hoping to gathering them
> > together. We define the mature project as those were used in product
> > environment massively, like the RocketMQ-JMS and RocketMQ-Console
> projects
> > from the RocketMQ’s first marathon campaign :-)
> >
> >
> > > 在 2017年3月19日，01:26，Bruce Snyder <bruce.sny...@gmail.com> 写道：
> > >
> > > Thanks for raising this question, Justin, as there is an important
> > > distinction here.
> > >
> > > Since the code that was not part of the core RocketMQ and was recently
> > > moved to the externals project was not migrated as part of the original
> > > move from Github to the ASF, it must be treated a bit differently. This
> > is
> > > especially true if folks who are not currently committers to the ASF
> > > RocketMQ project contributed to that code. We should have taken a more
> > > formal approach to moving over this code (my mistake for not
> recognizing
> > > this sooner). In terms of voting in the folks who contributed to this
> > code
> > > when it resided at Github vs. now that it resides at the ASF, there
> must
> > be
> > > a formal discussion of this amongst the PPMC about these potential
> > > committers in order to make this decision just like any other potential
> > > committers.
> > >
> > > It's also important to recognize that the ASF cannot provide the same
> > legal
> > > guarantees for code that was not officially contributed to the ASF vs.
> > code
> > > that goes through the proper legal process that has been established
> over
> > > the years at the ASF (like the original core RocketMQ code went
> through).
> > > This what code grants are all about and an important tenant of why the
> > ASF
> > > exists. I'm honestly not quite sure what to do here. Perhaps like
> Justin
> > > said above, getting ICLAs from the contributors and having the
> potential
> > > committer discussion about each of them right away.
> > >
> > > Justin, what are your further thoughts on this second topic?
> > >
> > > Bruce
> > >
> > > On Thu, Mar 16, 2017 at 8:43 PM, Justin Mclean <
> jus...@classsoftware.com
> > >
> > > wrote:
> > >
> > >> Hi,
> > >>
> > >>> And we want to adopt the same w

Re: [VOTE]: Release Apache RocketMQ 4.3.1 RC1

[yukon]

+1

On Wed, Aug 29, 2018 at 8:40 PM Shannon  wrote:

>
>
> +1
>
>
>
>
>
>
> At 2018-08-29 20:36:19, "heng du"  wrote:
> >Hello RocketMQ Community,
> >
> >This is the vote for 4.3.1 of Apache RocketMQ. We now kindly request the
> >RocketMQ community review and vote on this release artifact.
> >
> >Apache RocketMQ is a distributed messaging and streaming platform with low
> >latency, high performance and reliability, trillion-level capacity and
> >flexible scalability.
> >
> >This release is an enhancement and fix for the previous version, mainly
> >enhanced the compatibility of producer and fixed some issues, related
> >details could be found in the release notes.
> >
> >The artifacts:
> >https://dist.apache.org/repos/dist/dev/rocketmq/4.3.1-rc1/
> >
> >The staging repo:
> >https://repository.apache.org/content/repositories/orgapacherocketmq-1013
> >
> >Git tag for the release:
> >https://github.com/apache/rocketmq/tree/rocketmq-all-4.3.1
> >
> >Hash for the release tag: 4cef43670f3d28367569fe089ce300666b14416b
> >
> >Release Notes:
> >https://rocketmq.apache.org/release_notes/release-notes-4.3.1/
> >
> >The artifacts have been signed with Key : 133C87CA, 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
>

Re: GSOC - ROCKETMQ-380

[yukon]

   at java.lang.reflect.Method.invoke(Method.java:498)
> at org.springframework.aop.support.AopUtils.
> invokeJoinpointUsingReflection(AopUtils.java:333)
> at org.springframework.aop.framework.ReflectiveMethodInvocation.
> invokeJoinpoint(ReflectiveMethodInvocation.java:190)
> at org.springframework.aop.framework.ReflectiveMethodInvocation.
> proceed(ReflectiveMethodInvocation.java:157)
> at org.springframework.aop.aspectj.MethodInvocationProceedingJoin
> Point.proceed(MethodInvocationProceedingJoinPoint.java:85)
> at org.apache.rocketmq.console.aspect.admin.MQAdminAspect.
> aroundMQAdminMethod(MQAdminAspect.java:63)
> at sun.reflect.GeneratedMethodAccessor98.invoke(Unknown Source)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(
> DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:498)
> at org.springframework.aop.aspectj.AbstractAspectJAdvice.
> invokeAdviceMethodWithGivenArgs(AbstractAspectJAdvice.java:629)
> at org.springframework.aop.aspectj.AbstractAspectJAdvice.
> invokeAdviceMethod(AbstractAspectJAdvice.java:618)
> at org.springframework.aop.aspectj.AspectJAroundAdvice.
> invoke(AspectJAroundAdvice.java:70)
> at org.springframework.aop.framework.ReflectiveMethodInvocation.
> proceed(ReflectiveMethodInvocation.java:168)
> at org.springframework.aop.interceptor.
> ExposeInvocationInterceptor.invoke(ExposeInvocationInterceptor.java:92)
> at org.springframework.aop.framework.ReflectiveMethodInvocation.
> proceed(ReflectiveMethodInvocation.java:179)
> at org.springframework.aop.framework.JdkDynamicAopProxy.
> invoke(JdkDynamicAopProxy.java:213)
> at com.sun.proxy.$Proxy71.fetchAllTopicList(Unknown Source)
> at org.apache.rocketmq.console.task.DashboardCollectTask.
> collectTopic(DashboardCollectTask.java:79)
> ... 31 common frames omitted
>
>
> Log shown above. Thanks for the help.
>
> Best,
> Kailun
> From: yukon<mailto:yu...@apache.org>
> Sent: Monday, March 12, 2018 11:23 PM
> To: dev<mailto:dev@rocketmq.apache.org>
> Subject: Re: GSOC - ROCKETMQ-380
>
> Hi, could you please provide any log and the docker network model?
>
> On Tue, Mar 13, 2018 at 5:30 AM, p...@husky.neu.edu <p...@husky.neu.edu>
> wrote:
>
> > Hi Yukon,
> >
> > This is Kailun.
> >
> > I met a problem as I go through the console.
> >
> > In quick start, the console run in docker cannot connect to name server.
> >
> > Any idea what the problem is? Thanks for the help.
> >
> > Best,
> > Kailun
> >
>
>

Re: GSOC - ROCKETMQ-380

[yukon]

Hi, could you please provide any log and the docker network model?

On Tue, Mar 13, 2018 at 5:30 AM, p...@husky.neu.edu <p...@husky.neu.edu>
wrote:

> Hi Yukon,
>
> This is Kailun.
>
> I met a problem as I go through the console.
>
> In quick start, the console run in docker cannot connect to name server.
>
> Any idea what the problem is? Thanks for the help.
>
> Best,
> Kailun
>

Re: [GSOC][ROCKETMQ-380] Provide a modern and friendly console for RocketMQ

[yukon]

Hi,

This is a commercial version[1] of apache rocketmq and could be your
reference.

After trying this console, hope you could draft the design ASAP and then we
can discuss based on i.


Regards,
yukon

[1]. https://www.alibabacloud.com/product/mq

On Fri, Mar 16, 2018 at 2:41 AM, Ahmed Ifhaam <ahmedifha...@gmail.com>
wrote:

> Hi yukon,
>
> I checked the console and after you asked I have re checked it as well. I
> used it with the CLI tool in parallel too.
> In the requirement specification there was a reference console which I
> mentioned in my earlier mail that I couldn't get it to run. So I'm not
> exactly clear with the requirements. It would be a great help if someone
> can point me to a place where i can find the requirements. As I have to
> prepare the proposal (27th March) please kindly take a look at this ASAP.
>
> Thank you
>
> On Fri, Mar 9, 2018 at 9:05 PM, yukon <yu...@apache.org> wrote:
>
> > Edit the subject!
> >
> > On Fri, Mar 9, 2018 at 10:47 PM, yukon <yu...@apache.org> wrote:
> >
> > > Hi,
> > >
> > > ```
> > > The other thing is what are the expected features in the new console?
> > > ```
> > >
> > > Do you check out the features in the current console[1]?
> > >
> > > You may have ideas about the features after trying this console and the
> > > `admin` tool[2], then make a design and let's discuss based on it.
> > >
> > > Regards,
> > > yukon
> > >
> > > [1]. https://github.com/apache/rocketmq-externals/tree/
> > > master/rocketmq-console
> > > [2].https://github.com/apache/rocketmq/blob/master/
> > > distribution/bin/mqadmin
> > >
> > > On Thu, Mar 8, 2018 at 7:26 PM, Ahmed Ifhaam <ahmedifha...@gmail.com>
> > > wrote:
> > >
> > >> HI,
> > >> Regarding this RocketMQ-380,
> > >> I have issues in running the referenced console when ever i try to
> enter
> > >> my
> > >> personal details page is automatically redirected to home page.
> > >> Hence i'm not being able to activate the messaging service which i
> > believe
> > >> should work.
> > >> https://mns.console.aliyun.com/?spm=5176.2020520130.0.0.4db6
> > >> 3db5cHTXtU#/list/cn-hangzhou
> > >> From this link when i click activate button it is redirecting to the
> > home
> > >> page. but according to the documentation it should take me to a form
> to
> > >> fill my personal details. I created an account and i can login to my
> > >> account as well. Please help on this.
> > >>
> > >> The other thing is what are the expected features in the new console?
> > >> Please give a short description.
> > >>
> > >> Thanks in advance.
> > >>
> > >> On Wed, Mar 7, 2018 at 12:40 AM, Ahmed Ifhaam <ahmedifha...@gmail.com
> >
> > >> wrote:
> > >>
> > >> > Ok sorry, changing on bin/runbrocker.sh worked Thank you
> > >> >
> > >> > On Wed, Mar 7, 2018 at 12:27 AM, Sohaib Iftikhar <
> > sohaib1...@gmail.com>
> > >> > wrote:
> > >> >
> > >> >> Hi Ahmed,
> > >> >>
> > >> >> That file is for the nameserver. You also need to change the
> > JAVA_OPTS
> > >> for
> > >> >> the broker. Look at the fine `bin/runbroker.sh`.
> > >> >>
> > >> >> Thanks,
> > >> >> Sohaib
> > >> >>
> > >> >> On Tue, Mar 6, 2018 at 7:41 PM, Ahmed Ifhaam <
> ahmedifha...@gmail.com
> > >
> > >> >> wrote:
> > >> >>
> > >> >> > I tried the way you asked me to do, actually values were 4g only
> > even
> > >> >> > without changing but ichanged it back to 2gb also and tried no
> > effect
> > >> >> its
> > >> >> > taking 8 gb.
> > >> >> > I changed it in the file
> > >> >> > "distribution/target/apache-rocketmq/bin/runserver.sh" is it the
> > >> right
> > >> >> > file
> > >> >> > to change ?
> > >> >> >
> > >> >> > Thank you
> > >> >> >
> > >> >> > On Tue, Mar 6, 2018 at 12:00 PM, Ahmed Ifhaam <
> > >> ahmedifha...@gmail.com>
> > >> >> > wrote:
> > >> >> >
> &g

Re: 答复: [GSOC|ROCKETMQ-124] Support non-redundant message delivery mechanism

[yukon]

```
Personally, I find RAFT to be much simpler to implement. However, I do not
expect to reinvent the wheel here.
```

That's absolutely right, no need to reinvent the wheel, there are many
existing implementations for raft: https://raft.github.io/

```
I don't think using key store to persist all the messages is a good idea.
```

Yes, store an ID is enough.


On Thu, Mar 8, 2018 at 3:32 PM, Sohaib Iftikhar <sohaib1...@gmail.com>
wrote:

> Hi Dexin,
>
> Thank you for your suggestions. I will try to answer as much as I can and
> leave the rest to the RocketMQ team.
>
> 1. The idea with incremental Ids is actually quite good. But @Yukon
> mentioned that duplication can also be controlled by an application
> (special KV Property) in which case different producers may produce the
> same message that needs to deduplicated on the broker.
> SessionId+IncrementalId won't work in this scenario I believe. But we can
> actually switch to more efficient storage using the idea you described when
> the user is not specifying these special keys.
> Also I proposed storing of keys for only a fixed time interval. For all
> practical purposes this would still remain constant time. [Log base 2 of
> 10^10 is still just 33 :) ]. It does add the extra cost of communication
> but this would be the case in both scenarios.
> 2. As for consensus, the ideas I presented were pretty abstract so I
> mentioned a couple of algorithms that could potentially be used.
> Personally, I find RAFT to be much simpler to implement. However, I do not
> expect to reinvent the wheel here. I strongly believe that in this case, we
> can build upon some tested existing solution.
>
>
> Regards,
> Sohaib
>
> On Thu, Mar 8, 2018 at 1:31 AM, 李 德鑫 <dexi...@outlook.com> wrote:
>
> > Hi Sohaib,
> >
> >
> > I‘m a student applying for GSOC too. And I've read all of your discussion
> > in the mail list.
> >
> > I have some questions about your design, and some of the questions may
> > need to be answered by RocketMQ team. So I send them here to be
> discussed.
> >
> > I don't think using key store to persist all the messages is a good idea.
> > Since MQ is based on O(1) data structure. The key store would harm the
> > performance.
> >
> > I think we can learn from TCP protocol.
> >
> > In Producer-Broker Communication, we can give an incremental id for every
> > message sent in the same session. And the session id should be persistent
> > on the disk for producer. So the broker only need to maintain a map
> between
> > session id to expected message id(And this is how Kafka do it). Since
> > messages are much more than producers. However, there's still a K/V store
> > needed. So we have to ask RocketMQ team about how many producers in the
> > same time while in practical situation.
> >
> > Also, the same idea in Consumer-Broker Communication.
> >
> >
> > About consensus algorithm, I think RocketMQ should already have an
> > implementation there. I don't know what it is, but maybe you can reuse
> > that. Or what if you have to implement one, in my opinion, there's no
> need
> > to implement both Paxos and Raft. Since they solve the same kind of
> > problems.
> >
> >
> >
> > Regards,
> >
> > Dexin
> >
> >
> > 
> > 发件人: Sohaib Iftikhar <sohaib1...@gmail.com>
> > 发送时间: 2018年3月7日 18:15:51
> > 收件人: dev@rocketmq.apache.org
> > 主题: Re: [GSOC|ROCKETMQ-124] Support non-redundant message delivery
> > mechanism
> >
> > Hi Yukon,
> >
> > Thanks for your reply. Yes, it would be nice to concretely define the
> scope
> > of this project as the doc is a bit ambitious for just a summer. Should
> you
> > (or anyone else) have questions/suggestions/clarifications I'd be glad
> to
> > discuss more details.
> >
> > Thanks,
> > Sohaib
> >
> > On Wed, Mar 7, 2018 at 8:58 AM, yukon <yu...@apache.org> wrote:
> >
> > > Hi,
> > >
> > > Google doc is better for discussion, your design is great, now we could
> > > discuss more details base on it.
> > >
> > > Any advice is welcome from RocketMQ community.
> > >
> > > Appreciate your efforts.
> > >
> > > Regards,
> > > yukon
> > >
> > > On Wed, Mar 7, 2018 at 5:15 AM, Sohaib Iftikhar <sohaib1...@gmail.com>
> > > wrote:
> > >
> > > > Hi,
> > > >
> > > > @Yukon Thank you for your reply. This clears some doubts.
> > > >
> > > > Sorry fo

Re: [GSOC|ROCKETMQ-122] Support Global Ordered Messaging

[yukon]

Hi,

Of course, we can work together to finetune your design draft.

Regards,
yukon

On Thu, Mar 15, 2018 at 5:33 AM, sowmya s <sowmya9...@gmail.com> wrote:

> Hello, yukon and Von,
>
> I've shared my GSOC - 18 draft of the project. I'm looking forward to
> working with all of you to finetune the proposal. I will be allocating 20
> hours per week from now to the proposal acceptance phase to address
> questions and dive deep into any suggestions that you provide.
> I am really looking forward to work on this project.
>
> thanks,
> Sowmya
>
> On Tue, Mar 13, 2018 at 11:47 PM, sowmya s <sowmya9...@gmail.com> wrote:
>
> > Hello yukon,
> >
> > Thank you for the inputs. I was able to look at the ~/store and kind of
> > understand the storage structure. I also looked at the
> > DefaultMQProducerImpl and DefaultMQPullConsumerImpl, used in the
> examples.
> > Now I understand why you proposed a merge sort like approach for
> > performing global ordering. Since the proposals are open, I am finalizing
> > my draft and will have it up for review very soon.
> >
> > thanks,
> > Sowmya
> >
> > On Fri, Mar 9, 2018 at 7:03 AM, yukon <yu...@apache.org> wrote:
> >
> >> Hi Sowmya,
> >>
> >> ```
> >> Also, it would be great if you can at a high level, help me understand
> >> how the messages in the message queues are stored before the consumer
> reads
> >> them.
> >> ```
> >>
> >>
> >>
> >> As shown in this figure, messages are sent to brokers by producer and
> >> stored in commit log[1], then messages are dispatched to ConsumeQueue by
> >> topic, the consumer pulls messages from the queue.
> >>
> >> I recommend you run a broker and send/consume some messages, then check
> >> out the ~/store directory for details.
> >>
> >> Regards,
> >> yukon
> >>
> >> On Thu, Mar 8, 2018 at 12:09 PM, sowmya s <sowmya9...@gmail.com> wrote:
> >>
> >>> Hello yukon,
> >>>
> >>> Currently FIFO can be achieved with a producer sending to one message
> >>> queue, and when global ordering is required, multiple producers have to
> >>> send to a single topic queue.
> >>>
> >>> We want to allow multiple producers to send messages on a topic to
> >>> multiple message queues and still provide ordering guarantees to the
> >>> consumer, so that all consumers see the same order of data and also the
> >>> data is delivered in an ordered fashion.
> >>>
> >>> 1) Your idea of using a merge sort with the assumption that the first
> >>> arriving message is treated as the first message to be delivered,
> however,
> >>> I want to propose an approach where when the producer sends a message
> to a
> >>> message queue, it must be done in a synchronous fashion and the
> response
> >>> will be that the message is accepted, which means that the message
> follows
> >>> the convention that all messages delivered prior by that producer have
> been
> >>> stored across groups and if not the producer will need to resend the
> >>> message.
> >>>
> >>> We can use a variant of total causal ordering in the layer between the
> >>> message queue and store.
> >>>
> >>> I have been busy with my class project so I couldn't make a lot of
> >>> progress in detailing my approach. Also, it would be great if you can
> at a
> >>> high level, help me understand how the messages in the message queues
> are
> >>> stored before the consumer reads them.
> >>>
> >>> Does the consumer read directly from the message queue that the
> producer
> >>> sends data to? does the broker receive the queued producer messages,
> store
> >>> them and then pushes them to another queue for the consumer to read
> from?
> >>>
> >>> For reference on total causal ordering: https://www.cl.cam.ac.uk/teach
> >>> ing/0910/ConcDistS/10b-ProcGp-order.pdf
> >>>
> >>> thanks,
> >>> Sowmya
> >>>
> >>> On Mon, Mar 5, 2018 at 4:26 AM, yukon <yu...@apache.org> wrote:
> >>>
> >>>> Hi Sowmya,
> >>>>
> >>>> Sorry for the late reply, do you have any update on this project?
> >>>>
> >>>> In RocketMQ, one message queue is a FIFO queue natively, so I proposed
> >>>> a simple solution that performs

Re: [GSoC][ROCKETMQ-377] Implement a openwhisk-package-rocketmq to support serverless function

[yukon]

Hi,

I looked through your proposal, that's exactly what the issue needed, let's
move forward it.

Regards,
yukon


On Tue, Mar 27, 2018 at 8:48 AM, mayar.abdelaziz1...@gmail.com <
mayar.abdelaziz1...@gmail.com> wrote:

> Hi Yukon and Von,
>
> I have investigated the issue well and prepared a draft proposal. I am
> keen to work on this project and I am sorry for submitting the draft
> proposal late (it took from me some time to define the project on which I'd
> like to work).
>
> If you can review the proposal and inform me of any changes before the
> final submission date, I will be thankful to you.
>
> Here is a read and edit version of the proposal (developed in LaTeX):
> https://www.overleaf.com/15067483crttdvhcttnj
>
> Here is a read-only version of the proposal:
> https://drive.google.com/open?id=1LoeFaNvse1_k8v0hej_7T6rXzTPJhTzW
>
> I am looking forward to hearing from you..
>
> Thanks!
> Mayar
>
> On 2018/03/25 08:22:38, mayar.abdelaziz1...@gmail.com <
> mayar.abdelaziz1...@gmail.com> wrote:
> >
> > The objective of providing this package is to add RocketMQ as a new
> source of events, right?
> >
> > If so, Could you please guide me on how to start working on the project?
> >
> >
> > On 2018/03/25 05:22:27, yukon <yu...@apache.org> wrote:
> > > Hi,
> > >
> > > ```
> > > Do you want to replace the message passing system Kafka with RocketMQ
> in
> > > the OpenWhisk implementation?
> > > ```
> > >
> > > No, we want to provide a third-party package for OpenWhisk platform,
> like
> > > https://github.com/apache/incubator-openwhisk-package-kafka
> > >
> > > On Sun, Mar 25, 2018 at 9:02 AM, mayar.abdelaziz1...@gmail.com <
> > > mayar.abdelaziz1...@gmail.com> wrote:
> > >
> > > > Hi,
> > > >
> > > > I am Mayar Abd Elaziz, final year Computer Engineering student at
> Faculty
> > > > of Engineering, Alexandria university, Egypt. I am interested in
> working on
> > > > that project https://issues.apache.org/jira/browse/ROCKETMQ-377. I
> have
> > > > good knowledge on OpenWhisk because I am working in my graduation
> project
> > > > on it. I would like to get more understanding on the requirements of
> the
> > > > project as it's not so clear to me. Do you want to replace the
> message
> > > > passing system Kafka with RocketMQ in the OpenWhisk implementation?
> > > >
> > >
> >
>

Re: [GSOC|ROCKETMQ-122] Support Global Ordered Messaging

[yukon]

Cool, thanks for your efforts.

On Wed, Mar 28, 2018 at 9:02 AM, sowmya s <sowmya9...@gmail.com> wrote:

> Hello Yukon,
> I've submitted my final proposal addressing your comments as well. Hoping
> to work on this project for the summer. In the meantime i'm working on
> prototyping the global ordering approach i talked about in my proposal.
>
> thanks,
> Sowmya
>
> On Fri, Mar 23, 2018 at 4:48 AM, yukon <yu...@apache.org> wrote:
>
> > Hi,
> >
> > I added some comments, but it seems your google doc link isn't shared:
> >
> > ```
> > To resolve this issue, we need a global ordered messaging mechanism to
> have
> > a good scalability without hot-pot issue.
> >
> > A practical proposal is that sending messages to distributed
> > queue/partition with an ordered key. Messages are ordered in the same
> > queue, then implement an OrderConsumer to pull messages from these queues
> > then perform merge sort, finally deliver these ordered messages to users.
> > ```
> > As mentioned in ROCKETMQ-122, we should address the hot-pot issue.
> >
> > That means the messages can be sent to multiple distributed
> > queues/partitions and still can be consumed in order manner.
> >
> > A simple explanation of hot-pot issue:
> >
> > Assume that all the generated messages in a hot shop of taobao/amazon
> > should be consumed in order, in the current state, these massive messages
> > should be sent to a fixed queue/partition, surely to a fixed server which
> > may cause high pressure in this server. You can easily infer that we
> can't
> > resolve this issue through extending the scale of broker cluster.
> >
> > Could your arch resolve this hot-pot issue?
> >
> > Regards,
> > yukon
> >
> >
> > On Thu, Mar 22, 2018 at 2:15 PM, sowmya s <sowmya9...@gmail.com> wrote:
> >
> > > It's going great.
> > > In the DefaultMessageStore, there is a class
> > > CommitLogDispatcherBuildConsumeQueue, I think that a variant of that
> > class
> > > or another implementation which are merged from the commitlog,
> > > Since the DispachRequest has a store timestamp, the queue can be
> > populated
> > > based on that time stamp.
> > >
> > > Also, I have some more questions,
> > > Does the fleet of broker slaves all store the various commit logs that
> > are
> > > received by them or is the commit log store, replication managed by the
> > > broker controller?
> > >
> > > The other direction I was thinking about is adding/modifying the
> > > PullAPIWrapper, since the DefaultMQPushConsumerImpl uses the
> > > DefaultMQPullConsumerImpl and that uses the PullAPIWrapper, maybe
> adding
> > > this change there will solve the merge issue for the consumers.
> > >
> > > Do you think I am on the right track?
> > >
> > > thanks,
> > > Sowmya
> > >
> > >
> > >
> > > On Mon, Mar 19, 2018 at 8:15 PM, yukon <yu...@apache.org> wrote:
> > >
> > > > Hi,
> > > >
> > > > Sorry for the late reply.
> > > >
> > > > As for:
> > > >
> > > > ```
> > > > I'm looking at the BrokerController and MessageStore implementation
> and
> > > > hooks to understand where the merge logic will best fit.
> > > > ```
> > > >
> > > > how is it going?
> > > >
> > > > Regards
> > > >
> > > > On Sat, Mar 17, 2018 at 11:30 AM, sowmya s <sowmya9...@gmail.com>
> > wrote:
> > > >
> > > > > Thank you yukon,
> > > > >
> > > > > I'm done with my coursework for this semester and have more time
> now
> > to
> > > > > improve my proposal.
> > > > > I'm looking at the BrokerController and MessageStore implementation
> > and
> > > > > hooks to understand where the merge logic will best fit. So far
> I've
> > > > looked
> > > > > at the codebase from a Producer and Consumer perspective and looked
> > at
> > > > the
> > > > > DefaultMQProducerImpl and  DefaultMQPushConsumerImpl for
> > understanding
> > > > the
> > > > > link between how Producers send and Consumers receive messages.
> > > > >
> > > > > thanks,
> > > > > Sowmya
> > > > >
> > > > > On Fri, Mar 16, 2018 at 8:07 PM, yukon <yu...@apache.org&g

Re: [GSoC][ROCKETMQ-386] Provide an integration plugin with apache hbase

[yukon]

Hi,

You can pick up an issue from our JIRA system, the JIRA system is disabled
now but there are many existing issues need to be resolved.

Regards,
yukon

On Wed, Mar 28, 2018 at 2:17 AM, Madhushika Jayasinghe <
madhushikajayasinghe91...@gmail.com> wrote:

> Hi Yukon,
>
> I would like to fix an issue that is related to this project, to getting
> familiar with the project. It would be appreciated if you could point out
> any issue related to this.
>
> Thank you,
>
> Best Regards,
> Madhushika Jayasinghe.
>
>
>
> On Tue, Mar 27, 2018 at 3:41 PM Madhushika Jayasinghe <
> madhushikajayasinghe91...@gmail.com> wrote:
>
>> Hi Yukon,
>>
>> I have uploaded the final proposal in PDF format. I'm looking forward to
>> working with you in summer.
>>
>> Thank you,
>>
>> Best Regards,
>> Madhushika Jayasinghe.
>>
>> On Tue, Mar 27, 2018 at 7:39 AM yukon <yu...@apache.org> wrote:
>>
>>> Hi, your proposal looks great, we can forward it.
>>>
>>> On Mon, Mar 26, 2018 at 9:28 PM, Madhushika Jayasinghe <
>>> madhushikajayasinghe91...@gmail.com> wrote:
>>>
>>>> Hi Yukon,
>>>> I hope I could proceed with my original proposal. If there are any
>>>> concerns please let me know.
>>>>
>>>> Regrads,
>>>> Madhushika
>>>>
>>>>
>>>> On Sat, Mar 24, 2018 at 3:13 PM Madhushika Jayasinghe <
>>>> madhushikajayasinghe91...@gmail.com> wrote:
>>>>
>>>>> Hi Yukon,
>>>>> I have drafted proposal targeting the project "provide an integration
>>>>> plug-in with apache HBase". If you got free time please share your 
>>>>> feedback
>>>>> and views regarding this.
>>>>>
>>>>> Proposal: https://docs.google.com/document/d/
>>>>> 1NjWaJcJQd1ex0Zc5bJ1NKRiQH4L2Wh7Lx1Un2qI498c/edit?usp=sharing
>>>>>
>>>>> Thank you.
>>>>>
>>>>>
>>>>> On Thu, Mar 22, 2018 at 7:38 AM yukon <yu...@apache.org> wrote:
>>>>>
>>>>>> Please refer to here:
>>>>>> https://dev.mysql.com/doc/refman/5.7/en/binary-log.html
>>>>>>
>>>>>> On Thu, Mar 22, 2018 at 1:55 AM, Madhushika Jayasinghe <
>>>>>> madhushikajayasinghe91...@gmail.com> wrote:
>>>>>>
>>>>>> > Hi,
>>>>>> > In my proposal I am going to suggest a method quite similar to MySQL
>>>>>> > plug-in. There is a replicator class which acts as a interface for
>>>>>> push and
>>>>>> > pull requests. Internally it will communicate with HBase and store
>>>>>> required
>>>>>> > data.
>>>>>> > In MySQL repo it has heavily mentioned about binlog. What is this
>>>>>> binlog
>>>>>> > and how is it related to RocketMQ?
>>>>>> > Thanks
>>>>>> >
>>>>>> > Regards,
>>>>>> > Madhushika
>>>>>> >
>>>>>> > On Wed, Mar 21, 2018 at 8:10 AM yukon <yu...@apache.org> wrote:
>>>>>> >
>>>>>> > > Hi,
>>>>>> > >
>>>>>> > > Sorry to have misled you, I mean the plugin could bring the
>>>>>> ability of
>>>>>> > > off-line storage to RocketMQ.
>>>>>> > >
>>>>>> > > As for the plugin, should contain sink and source connectors to
>>>>>> send and
>>>>>> > > pull data from HBase.
>>>>>> > >
>>>>>> > > Regards,
>>>>>> > > yukon
>>>>>> > >
>>>>>> > > On Wed, Mar 21, 2018 at 1:28 AM, Madhushika Jayasinghe <
>>>>>> > > madhushikajayasinghe91...@gmail.com> wrote:
>>>>>> > >
>>>>>> > >> Hi,
>>>>>> > >> I am Madhushika Jayasinghe, a final year undergraduate from
>>>>>> Computer
>>>>>> > >> Science and Engineering Department, University of Moratuwa. As I
>>>>>> > previously
>>>>>> > >> mentioned in the JIRA I am working for the above project as GSoC
>>>>>> > Project.
>>>>>> > >> Currently I have cloned the RocketMQ Repo and followed some
>>>>>> > documentation
>>>>>> > >> to be familiar with RocketMQ. Now I am in the process of
>>>>>> drafting a
>>>>>> > >> proposal and got few questions.
>>>>>> > >> In the JIRA it is mentioned that the "plugin should have the
>>>>>> capability
>>>>>> > >> of off-line storage". Here what is meant by off-line storage?
>>>>>> And how
>>>>>> > can I
>>>>>> > >> tackle this case?
>>>>>> > >>
>>>>>> > >>
>>>>>> > >> Thanks
>>>>>> > >>
>>>>>> > >> Regards,
>>>>>> > >> Madhushika
>>>>>> > >>
>>>>>> > >
>>>>>> > >
>>>>>> >
>>>>>>
>>>>>
>>>

Re: [GSoC][ROCKETMQ-386] Provide an integration plugin with apache hbase

[yukon]

Also, you can use SonarQube or findbugs to scan the code base of RocketMQ,
I am sure you will find some major issues which can be addressed easily.

Regards,
yukon

On Wed, Mar 28, 2018 at 9:54 AM, yukon <yu...@apache.org> wrote:

> Hi,
>
> You can pick up an issue from our JIRA system, the JIRA system is disabled
> now but there are many existing issues need to be resolved.
>
> Regards,
> yukon
>
> On Wed, Mar 28, 2018 at 2:17 AM, Madhushika Jayasinghe <
> madhushikajayasinghe91...@gmail.com> wrote:
>
>> Hi Yukon,
>>
>> I would like to fix an issue that is related to this project, to getting
>> familiar with the project. It would be appreciated if you could point out
>> any issue related to this.
>>
>> Thank you,
>>
>> Best Regards,
>> Madhushika Jayasinghe.
>>
>>
>>
>> On Tue, Mar 27, 2018 at 3:41 PM Madhushika Jayasinghe <
>> madhushikajayasinghe91...@gmail.com> wrote:
>>
>>> Hi Yukon,
>>>
>>> I have uploaded the final proposal in PDF format. I'm looking forward to
>>> working with you in summer.
>>>
>>> Thank you,
>>>
>>> Best Regards,
>>> Madhushika Jayasinghe.
>>>
>>> On Tue, Mar 27, 2018 at 7:39 AM yukon <yu...@apache.org> wrote:
>>>
>>>> Hi, your proposal looks great, we can forward it.
>>>>
>>>> On Mon, Mar 26, 2018 at 9:28 PM, Madhushika Jayasinghe <
>>>> madhushikajayasinghe91...@gmail.com> wrote:
>>>>
>>>>> Hi Yukon,
>>>>> I hope I could proceed with my original proposal. If there are any
>>>>> concerns please let me know.
>>>>>
>>>>> Regrads,
>>>>> Madhushika
>>>>>
>>>>>
>>>>> On Sat, Mar 24, 2018 at 3:13 PM Madhushika Jayasinghe <
>>>>> madhushikajayasinghe91...@gmail.com> wrote:
>>>>>
>>>>>> Hi Yukon,
>>>>>> I have drafted proposal targeting the project "provide an integration
>>>>>> plug-in with apache HBase". If you got free time please share your 
>>>>>> feedback
>>>>>> and views regarding this.
>>>>>>
>>>>>> Proposal: https://docs.google.com/docume
>>>>>> nt/d/1NjWaJcJQd1ex0Zc5bJ1NKRiQH4L2Wh7Lx1Un2qI498c/edit?usp=sharing
>>>>>>
>>>>>> Thank you.
>>>>>>
>>>>>>
>>>>>> On Thu, Mar 22, 2018 at 7:38 AM yukon <yu...@apache.org> wrote:
>>>>>>
>>>>>>> Please refer to here:
>>>>>>> https://dev.mysql.com/doc/refman/5.7/en/binary-log.html
>>>>>>>
>>>>>>> On Thu, Mar 22, 2018 at 1:55 AM, Madhushika Jayasinghe <
>>>>>>> madhushikajayasinghe91...@gmail.com> wrote:
>>>>>>>
>>>>>>> > Hi,
>>>>>>> > In my proposal I am going to suggest a method quite similar to
>>>>>>> MySQL
>>>>>>> > plug-in. There is a replicator class which acts as a interface for
>>>>>>> push and
>>>>>>> > pull requests. Internally it will communicate with HBase and store
>>>>>>> required
>>>>>>> > data.
>>>>>>> > In MySQL repo it has heavily mentioned about binlog. What is this
>>>>>>> binlog
>>>>>>> > and how is it related to RocketMQ?
>>>>>>> > Thanks
>>>>>>> >
>>>>>>> > Regards,
>>>>>>> > Madhushika
>>>>>>> >
>>>>>>> > On Wed, Mar 21, 2018 at 8:10 AM yukon <yu...@apache.org> wrote:
>>>>>>> >
>>>>>>> > > Hi,
>>>>>>> > >
>>>>>>> > > Sorry to have misled you, I mean the plugin could bring the
>>>>>>> ability of
>>>>>>> > > off-line storage to RocketMQ.
>>>>>>> > >
>>>>>>> > > As for the plugin, should contain sink and source connectors to
>>>>>>> send and
>>>>>>> > > pull data from HBase.
>>>>>>> > >
>>>>>>> > > Regards,
>>>>>>> > > yukon
>>>>>>> > >
>>>>>>> > > On Wed, Mar 21, 2018 at 1:28 AM, Madhushika Jayasinghe <
>>>>>>> > > madhushikajayasinghe91...@gmail.com> wrote:
>>>>>>> > >
>>>>>>> > >> Hi,
>>>>>>> > >> I am Madhushika Jayasinghe, a final year undergraduate from
>>>>>>> Computer
>>>>>>> > >> Science and Engineering Department, University of Moratuwa. As I
>>>>>>> > previously
>>>>>>> > >> mentioned in the JIRA I am working for the above project as GSoC
>>>>>>> > Project.
>>>>>>> > >> Currently I have cloned the RocketMQ Repo and followed some
>>>>>>> > documentation
>>>>>>> > >> to be familiar with RocketMQ. Now I am in the process of
>>>>>>> drafting a
>>>>>>> > >> proposal and got few questions.
>>>>>>> > >> In the JIRA it is mentioned that the "plugin should have the
>>>>>>> capability
>>>>>>> > >> of off-line storage". Here what is meant by off-line storage?
>>>>>>> And how
>>>>>>> > can I
>>>>>>> > >> tackle this case?
>>>>>>> > >>
>>>>>>> > >>
>>>>>>> > >> Thanks
>>>>>>> > >>
>>>>>>> > >> Regards,
>>>>>>> > >> Madhushika
>>>>>>> > >>
>>>>>>> > >
>>>>>>> > >
>>>>>>> >
>>>>>>>
>>>>>>
>>>>
>

Re: [GSoC][ROCKETMQ-377] Implement a openwhisk-package-rocketmq to support serverless function

[yukon]

Hi,

```
Do you want to replace the message passing system Kafka with RocketMQ in
the OpenWhisk implementation?
```

No, we want to provide a third-party package for OpenWhisk platform, like
https://github.com/apache/incubator-openwhisk-package-kafka

On Sun, Mar 25, 2018 at 9:02 AM, mayar.abdelaziz1...@gmail.com <
mayar.abdelaziz1...@gmail.com> wrote:

> Hi,
>
> I am Mayar Abd Elaziz, final year Computer Engineering student at Faculty
> of Engineering, Alexandria university, Egypt. I am interested in working on
> that project https://issues.apache.org/jira/browse/ROCKETMQ-377. I have
> good knowledge on OpenWhisk because I am working in my graduation project
> on it. I would like to get more understanding on the requirements of the
> project as it's not so clear to me. Do you want to replace the message
> passing system Kafka with RocketMQ in the OpenWhisk implementation?
>

Re: The State of RocketMQ Streaming Integration

[yukon]

Thanks, Xin!

These plugins have greatly enriched the RocketMQ community, hope we could
get more feedback from the community about these plugins.

Regards,
yukon


On Mon, Mar 26, 2018 at 10:44 AM, Xin Wang <data.xinw...@gmail.com> wrote:

> Hi folks,
>
> I'm glad to say that the RocketMQ-Flink module has been merged into master.
> https://github.com/apache/rocketmq-externals/tree/master/rocketmq-flink
>
> Here is the state of rocketmq streaming integration:
>ModuleStatus
> * RocketMQ-Storm*Available*
> * RocketMQ-Spark*Available*, *The improvements will be available soon*.
> * RocketMQ-Flink *Available*
> * RocketMQ-Serializer(including JSON, Apache Avro)*Available*, *Not
> merged yet*.
>
> And, some new modules on the road:
> * RocketMQ-SQL  https://issues.apache.org/jira/browse/ROCKETMQ-357
> * RocketMQ-Beam(Beam IO)
>
>
> Anybody who is interested in these tasks too, please join me. Let's fight
> together.
>
>
> Thanks,
> Xin Wang
>
>
>
> 2018-01-27 19:35 GMT+08:00 Xin Wang <data.xinw...@gmail.com>:
>
> > Hi devs,
> >
> > I'd like to update the state of RocketMQ Streaming Integration:
> > Now the task for RocketMQ-Flink  integration is completed and  patch is
> > available here: https://github.com/apache/rocketmq-externals/pull/45
> > Following is the brief changelog:
> >
> >- RocketMQSource - The RocketMQSource is based on RocketMQ pull
> >consumer mode, and provides exactly once reliability guarantees when
> >checkpoints are enabled.
> >Otherwise, the source doesn't provide any reliability guarantees.
> >- RocketMQSink - The RocketMQSink provides at-least-once reliability
> >guarantees when checkpoints are enabled and withBatchFlushOnCheckpoint
> >(true) is set.
> >Otherwise, the sink reliability guarantees depends on rocketmq
> >producer's retry policy, for this case, the messages sending way is
> sync by
> >default,
> >but you can change it by invoking withAsync(true).
> >- KeyValueDeserializationSchema - The main API for deserializing topic
> >and tags is the org.apache.rocketmq.flink.common.serialization.
> >KeyValueDeserializationSchema interface.
> >rocketmq-flink includes general purpose KeyValueDeserializationSchema
> implementations
> >called SimpleKeyValueDeserializationSchema.
> >- KeyValueSerializationSchema - The main API for serializing topic and
> >tags is the org.apache.rocketmq.flink.common.serialization.
> >KeyValueSerializationSchema interface.
> >rocketmq-flink includes general purpose KeyValueSerializationSchema
> implementations
> >called SimpleKeyValueSerializationSchema.
> >- TopicSelector - The main API for selecting topic and tags is the
> >org.apache.rocketmq.flink.common.selector.TopicSelector interface.
> >rocketmq-flink includes general purpose TopicSelector implementations
> >called DefaultTopicSelector and SimpleTopicSelector.
> >- RocketMQFlinkExample - which receive messages from RocketMQ brokers
> >and send messages to broker after processing.
> >
> > Any comments are welcome. And anybody who is also interested in these
> > tasks, please join me. Let's fight together.
> >
> > Thanks,
> > Xin Wang
> >
> >
> > 2018-01-19 21:47 GMT+08:00 yukon <yu...@apache.org>:
> >
> >> Cool, thanks for your outstanding contribution, to help RocketMQ
> community
> >> integrate with other streaming platforms.
> >>
> >> On Fri, Jan 19, 2018 at 7:52 PM, Xin Wang <data.xinw...@gmail.com>
> wrote:
> >>
> >> > Hi devs,
> >> >
> >> > I have finished the improvements for integrating RocketMQ with Apache
> >> > Storm.
> >> > Main changes are as following:
> >> >
> >> >- Upgraded RocketMQ version to 4.2.0 which brings improvements and
> >> new
> >> >features like batch sending
> >> >- Imporved retry policy for RocketMQ consumer push mode to avoid
> data
> >> >loss in some scenes
> >> >- Batch sending supported for bolt and trident state
> >> >- Allow running several consumer instances in one process, that is
> to
> >> >say, different topics in one worker is possible
> >> >
> >> > PR: https://github.com/apache/storm/pull/2518
> >> >
> >> > And I submit the `RocketMQ-Serializer` patch several days ago. This
> >> module
> >> > includes several serialization

Re: [GSOC2018][ROCKETMQ-379] Support AMQP protocol for RocketMQ-Proposal

[yukon]

Looks great, let's upload it.

On Mon, Mar 26, 2018 at 6:21 AM, Ratnasingam Kasthuriraajan <
kasthuriraaja...@gmail.com> wrote:

> Hi Yukon, Von
>
> I have updated my draft proposal in a new link with the appropriate  could
> you please check it.
>
> https://docs.google.com/document/d/1YOFbdlfPrels6A9lHMqDTdJ6VjPF_
> XRBgVj7S_oEVtI/edit?usp=sharing
>
> Once you check it, I can upload it into the GSOC page.
>
> Thanks & Reegards
> R.Kasthuriraajan
> --
> R.Kasthuriraajan.
> Undergraduate student | Department of Computer Science,
> Faculty of Science | University of Jaffna.
>
> LinkedIn: https://www.linkedin.com/in/ratnasingam-
> kasthuriraajan-2a6892121/
> <https://www.linkedin.com/in/ratnasingam-kasthuriraajan-2a6892121/>
> stackoverflow: https://stackoverflow.com/users/8870269/kasthuriraajan?tab=
> profile
> GitHub: https://github.com/kasthuriraajan
> Medium: https://medium.com/@Kasthuriraajan
>
>

Re: [GSOC][ROCKETMQ-127]Providing a rocketmq-proxy to support MQTT protocol

[yukon]

As we are implementing a proxy server, so may Linkerd[1] could give us some
hints.

[1]. https://linkerd.io/

Regards,
yukon

On Fri, Mar 16, 2018 at 9:38 PM, Sudaraka Yasindu <sudarakayasi...@gmail.com
> wrote:

> Thank you for the clarification Yukon. I am looking into it.
>
> Regards,
> Sudaraka Jayathilaka
> *Undergraduate*
> Department of Computer Science and Engineering
> University of Moratuwa
>
>
> On Fri, Mar 16, 2018 at 6:42 PM, yukon <yu...@apache.org> wrote:
>
> > Hi,
> >
> > A paper implemented a MQTT push server based on RocketMQ, maybe it helps.
> >
> > And we don't want to depend on the third-party server, just develop a
> > proxy server that supports MQTT protocol and talk to our rocketmq
> cluster.
> >
> > Regards,
> > yukon
> >
> > 1. Yue, Ma, et al. "A MQTT Protocol Message Push Server Based on
> > RocketMQ." Intelligent Computation Technology and Automation (ICICTA),
> 2017
> > 10th International Conference on. IEEE, 2017.
> >
> >
> >
> > On Fri, Mar 16, 2018 at 8:18 PM, Sudaraka Yasindu <
> > sudarakayasi...@gmail.com> wrote:
> >
> >> ​Hi Yukon & Vongosling,
> >> I started experimenting with Eclipse Mosquitto as it has been used in
> >> many projects. Will it be suitable to be used in the project as Yukon
> >> mentioned in Jira or should I choose another MQTT broker? . I created
> this
> >> with my current understanding about the project.
> >> ​
> >>
> >> Is the main target of the proxy server implementation is to add the
> >> protocol conversion functionality?. Can you please give me your inputs
> on
> >> the above diagram. Thank you
> >>
> >> Regards,
> >> Sudaraka Jayathilaka
> >> *Undergraduate*
> >> Department of Computer Science and Engineering
> >> University of Moratuwa
> >>
> >>
> >> On Sat, Mar 10, 2018 at 12:12 AM, Sudaraka Yasindu <
> >> sudarakayasi...@gmail.com> wrote:
> >>
> >>> I'm really sorry if my diagram is not visible in the previous email. I
> >>> will attach it here in case it isn't visible
> >>>
> >>>
> >>> Regards,
> >>> Sudaraka Jayathilaka
> >>> *Undergraduate*
> >>> Department of Computer Science and Engineering
> >>> University of Moratuwa
> >>> m: +94715271890 <+94%2071%20527%201890>
> >>> e: sudarakayasi...@gmail.com
> >>> <https://web.facebook.com/sudara.yasi>
> >>> <https://twitter.com/Sudaraka94>
> >>> <https://www.linkedin.com/in/sudarakajayathilaka>
> >>> <https://www.instagram.com/sudaraka94/>
> >>>
> >>>
> >>> On Fri, Mar 9, 2018 at 11:57 PM, Sudaraka Yasindu <
> >>> sudarakayasi...@gmail.com> wrote:
> >>>
> >>>> Hi Yukon,
> >>>> I will continue my discussion here from now on (Which I continued on
> >>>> JIRA). As per my understanding, MQTT protocol follows a publisher
> >>>> subscriber publish subscribe architecture. I read the RocketMQ
> >>>> documentation and it occurred to me that, message broadcasting using
> >>>> RocketMQ can be used here. I ran these examples and I got a brief
> knowledge
> >>>> on working with message broadcasting with RocketMQ.
> >>>> I thought of a setup where each IoT Sensor(device which produces
> >>>> messages) sends messages with a unique topic. So the subscribers can
> >>>> subscribe to the message stream using the same unique topic. I
> sketched my
> >>>> current idea like this.
> >>>>
> >>>> But still I'm not sure this requires separate proxy for publishers and
> >>>> a separate proxy for subscribers. Can you please input your
> suggestions.
> >>>> Thank you.
> >>>>
> >>>> Regards,
> >>>> Sudaraka Jayathilaka
> >>>> *Undergraduate*
> >>>> Department of Computer Science and Engineering
> >>>> University of Moratuwa
> >>>> m: +94715271890 <+94%2071%20527%201890>
> >>>> e: sudarakayasi...@gmail.com
> >>>> <https://web.facebook.com/sudara.yasi>
> >>>> <https://twitter.com/Sudaraka94>
> >>>> <https://www.linkedin.com/in/sudarakajayathilaka>
> >>>> <https://www.instagram.com/sudaraka94/>
> >>>>
> >>>>
> >>>
> >>
> >
>

Re: [GSOC|ROCKETMQ-122] Support Global Ordered Messaging

[yukon]

Cool, let's focus on it and see whether is there anything can be polished.

Regards

On Fri, Mar 16, 2018 at 11:54 PM, sowmya s <sowmya9...@gmail.com> wrote:

> Hey yukon,
> I submitted my draft on the summer of code homepage a couple of days ago,
> also attaching the link here for reference,
>
> https://docs.google.com/file/d/1nXktUO_TF9-rSHSnGj5z5QZoHzMhosxm/edit?
> usp=docslist_api=msword
>
> Thanks,
> Sowmya
>
> On Thu, Mar 15, 2018 at 2:08 AM yukon <yu...@apache.org> wrote:
>
> > Hi,
> >
> > Of course, we can work together to finetune your design draft.
> >
> > Regards,
> > yukon
> >
> > On Thu, Mar 15, 2018 at 5:33 AM, sowmya s <sowmya9...@gmail.com> wrote:
> >
> > > Hello, yukon and Von,
> > >
> > > I've shared my GSOC - 18 draft of the project. I'm looking forward to
> > > working with all of you to finetune the proposal. I will be allocating
> 20
> > > hours per week from now to the proposal acceptance phase to address
> > > questions and dive deep into any suggestions that you provide.
> > > I am really looking forward to work on this project.
> > >
> > > thanks,
> > > Sowmya
> > >
> > > On Tue, Mar 13, 2018 at 11:47 PM, sowmya s <sowmya9...@gmail.com>
> wrote:
> > >
> > > > Hello yukon,
> > > >
> > > > Thank you for the inputs. I was able to look at the ~/store and kind
> of
> > > > understand the storage structure. I also looked at the
> > > > DefaultMQProducerImpl and DefaultMQPullConsumerImpl, used in the
> > > examples.
> > > > Now I understand why you proposed a merge sort like approach for
> > > > performing global ordering. Since the proposals are open, I am
> > finalizing
> > > > my draft and will have it up for review very soon.
> > > >
> > > > thanks,
> > > > Sowmya
> > > >
> > > > On Fri, Mar 9, 2018 at 7:03 AM, yukon <yu...@apache.org> wrote:
> > > >
> > > >> Hi Sowmya,
> > > >>
> > > >> ```
> > > >> Also, it would be great if you can at a high level, help me
> understand
> > > >> how the messages in the message queues are stored before the
> consumer
> > > reads
> > > >> them.
> > > >> ```
> > > >>
> > > >>
> > > >>
> > > >> As shown in this figure, messages are sent to brokers by producer
> and
> > > >> stored in commit log[1], then messages are dispatched to
> ConsumeQueue
> > by
> > > >> topic, the consumer pulls messages from the queue.
> > > >>
> > > >> I recommend you run a broker and send/consume some messages, then
> > check
> > > >> out the ~/store directory for details.
> > > >>
> > > >> Regards,
> > > >> yukon
> > > >>
> > > >> On Thu, Mar 8, 2018 at 12:09 PM, sowmya s <sowmya9...@gmail.com>
> > wrote:
> > > >>
> > > >>> Hello yukon,
> > > >>>
> > > >>> Currently FIFO can be achieved with a producer sending to one
> message
> > > >>> queue, and when global ordering is required, multiple producers
> have
> > to
> > > >>> send to a single topic queue.
> > > >>>
> > > >>> We want to allow multiple producers to send messages on a topic to
> > > >>> multiple message queues and still provide ordering guarantees to
> the
> > > >>> consumer, so that all consumers see the same order of data and also
> > the
> > > >>> data is delivered in an ordered fashion.
> > > >>>
> > > >>> 1) Your idea of using a merge sort with the assumption that the
> first
> > > >>> arriving message is treated as the first message to be delivered,
> > > however,
> > > >>> I want to propose an approach where when the producer sends a
> message
> > > to a
> > > >>> message queue, it must be done in a synchronous fashion and the
> > > response
> > > >>> will be that the message is accepted, which means that the message
> > > follows
> > > >>> the convention that all messages delivered prior by that producer
> > have
> > > been
> > > >>> stored across groups and if not the producer will need to resend
> the
> > >

Re: [GSoC][ROCKETMQ-386] Provide an integration plugin with apache hbase

[yukon]

Hi,

Sorry to have misled you, I mean the plugin could bring the ability of
off-line storage to RocketMQ.

As for the plugin, should contain sink and source connectors to send and
pull data from HBase.

Regards,
yukon

On Wed, Mar 21, 2018 at 1:28 AM, Madhushika Jayasinghe <
madhushikajayasinghe91...@gmail.com> wrote:

> Hi,
> I am Madhushika Jayasinghe, a final year undergraduate from Computer
> Science and Engineering Department, University of Moratuwa. As I previously
> mentioned in the JIRA I am working for the above project as GSoC Project.
> Currently I have cloned the RocketMQ Repo and followed some documentation
> to be familiar with RocketMQ. Now I am in the process of drafting a
> proposal and got few questions.
> In the JIRA it is mentioned that the "plugin should have the capability of
> off-line storage". Here what is meant by off-line storage? And how can I
> tackle this case?
>
>
> Thanks
>
> Regards,
> Madhushika
>

[ANNOUNCE] JIRA system has been disabled for RocketMQ

[yukon]

Hi all,

We have disabled JIRA system and enabled GitHub issue, please use Github
Issue for the new bug report and feature request.

And there are some ongoing GSoC projects in JIRA system, please open a
thread on dev list to discuss and track them.

Regards,
yukon

Re: [GSoC][ROCKETMQ-386] Provide an integration plugin with apache hbase

[yukon]

Please refer to here:
https://dev.mysql.com/doc/refman/5.7/en/binary-log.html

On Thu, Mar 22, 2018 at 1:55 AM, Madhushika Jayasinghe <
madhushikajayasinghe91...@gmail.com> wrote:

> Hi,
> In my proposal I am going to suggest a method quite similar to MySQL
> plug-in. There is a replicator class which acts as a interface for push and
> pull requests. Internally it will communicate with HBase and store required
> data.
> In MySQL repo it has heavily mentioned about binlog. What is this binlog
> and how is it related to RocketMQ?
> Thanks
>
> Regards,
> Madhushika
>
> On Wed, Mar 21, 2018 at 8:10 AM yukon <yu...@apache.org> wrote:
>
> > Hi,
> >
> > Sorry to have misled you, I mean the plugin could bring the ability of
> > off-line storage to RocketMQ.
> >
> > As for the plugin, should contain sink and source connectors to send and
> > pull data from HBase.
> >
> > Regards,
> > yukon
> >
> > On Wed, Mar 21, 2018 at 1:28 AM, Madhushika Jayasinghe <
> > madhushikajayasinghe91...@gmail.com> wrote:
> >
> >> Hi,
> >> I am Madhushika Jayasinghe, a final year undergraduate from Computer
> >> Science and Engineering Department, University of Moratuwa. As I
> previously
> >> mentioned in the JIRA I am working for the above project as GSoC
> Project.
> >> Currently I have cloned the RocketMQ Repo and followed some
> documentation
> >> to be familiar with RocketMQ. Now I am in the process of drafting a
> >> proposal and got few questions.
> >> In the JIRA it is mentioned that the "plugin should have the capability
> >> of off-line storage". Here what is meant by off-line storage? And how
> can I
> >> tackle this case?
> >>
> >>
> >> Thanks
> >>
> >> Regards,
> >> Madhushika
> >>
> >
> >
>

Re: [GSOC][ROCKETMQ-127]Providing a rocketmq-proxy to support MQTT protocol

[yukon]

Looks great, I added some comments~

On Thu, Mar 22, 2018 at 5:19 PM, Sudaraka Yasindu <sudarakayasi...@gmail.com
> wrote:

> Hi Yukon and Von,
> I started drafting my proposal. Can you please take a look and let me know
> whether I should change the content or add something more. I already shared
> the proposal through GSoC dashboard. Thank you
>
> Proposal :
> https://docs.google.com/document/d/1A3XY3KPz-
> yUTubWK2ij1oXJneOis45a1kB6Qwefbh9U/edit?usp=sharing
>
> Regards,
> Sudaraka Jayathilaka
> *Undergraduate*
> Department of Computer Science and Engineering
> University of Moratuwa
>
>
> On Tue, Mar 20, 2018 at 8:39 AM, yukon <yu...@apache.org> wrote:
>
> > Great, you should ensure that the vert.x mqtt server has enough secondary
> > development capabilities if you want to reuse it. After all, we need the
> > server react with RocketMQ cluster.
> >
> > Regards
> >
> > On Tue, Mar 20, 2018 at 2:45 AM, Sudaraka Yasindu <
> > sudarakayasi...@gmail.com
> > > wrote:
> >
> > > Hi Yukon and Von,
> > > I found Vert.x MQTT server[1] provides a nice way of implementing MQTT
> > > broker functionality. I just played around and created a simple mqtt
> > broker
> > > with it. The repo is on github[2]  and I have uploaded a short
> screencast
> > > to the google drive[3]. I used MQTTLens[4] as the MQTT client here.
> Thank
> > > you
> > >
> > > [1] http://vertx.io/docs/vertx-mqtt-server/java/
> > > [2] https://github.com/sudaraka94/mqtt-broker-test
> > > [3] https://drive.google.com/open?id=1W4QOCRsONYr4Tl7RSDolqQHnNgRwJQUY
> > > [4] https://chrome.google.com/webstore/detail/mqttlens/hemoj
> > > aaeigabkbcookmlgmdigohjobjm
> > >
> > > Regards,
> > > Sudaraka Jayathilaka
> > > *Undergraduate*
> > > Department of Computer Science and Engineering
> > > University of Moratuwa
> > >
> > >
> > > On Tue, Mar 20, 2018 at 12:08 AM, Sudaraka Yasindu <
> > > sudarakayasi...@gmail.com> wrote:
> > >
> > >> Hi Yukon and Von,
> > >> I found Vert.x MQTT server[1] provides a nice way of implementing MQTT
> > >> broker functionality. I just played around and created a simple mqtt
> > broker
> > >> with it. The repo is on github[2]  and I have attached a short screen
> > cast
> > >> with this email. I used MQTTLens[3] as the MQTT client here. Thank you
> > >>
> > >> [1] http://vertx.io/docs/vertx-mqtt-server/java/
> > >> [2] https://github.com/sudaraka94/mqtt-broker-test
> > >> [3] https://chrome.google.com/webstore/detail/mqttlens/hemoj
> > >> aaeigabkbcookmlgmdigohjobjm
> > >>
> > >> Regards,
> > >> Sudaraka Jayathilaka
> > >> *Undergraduate*
> > >> Department of Computer Science and Engineering
> > >> University of Moratuwa
> > >>
> > >>
> > >> On Sat, Mar 17, 2018 at 2:27 PM, yukon <yu...@apache.org> wrote:
> > >>
> > >>> Cool, looking forward to your design and reuse code is ok if the
> > license
> > >>> is compatible with ASF license. More details please refer to
> > >>> https://www.apache.org/legal/resolved.html
> > >>> <https://www.apache.org/legal/resolved.html#category-b>
> > >>>
> > >>> Sudaraka Yasindu <sudarakayasi...@gmail.com>于2018年3月17日 周六下午3:53写道：
> > >>>
> > >>>> Hi Yukon and Von Gosling,
> > >>>> I read the research paper you mentioned in the thread and got a
> brief
> > >>>> idea about the proxy server and its functionalities
> > >>>>
> > >>>>
> > >>>> I figured the proxy server implementation must have mainly two
> > >>>> components. One component for handling all the functionalities
> > regarding
> > >>>> the ​MQTT protocol and the other component which is responsible for
> > >>>> translating messages between RocketMQ message format and MQTT
> message
> > >>>> format.
> > >>>>
> > >>>> *MQTT Broker*
> > >>>>
> > >>>> I found a lot of existing opensource MQTT Broker implementations. I
> > >>>> found Eclipse Mosquitto easy to work with. In the project I will be
> > able to
> > >>>> use one of these brokers as references and implement the component
> > myself.
> > >>&g

Re: [GSOC][ROCKETMQ-127]Providing a rocketmq-proxy to support MQTT protocol

[yukon]

Great, you should ensure that the vert.x mqtt server has enough secondary
development capabilities if you want to reuse it. After all, we need the
server react with RocketMQ cluster.

Regards

On Tue, Mar 20, 2018 at 2:45 AM, Sudaraka Yasindu <sudarakayasi...@gmail.com
> wrote:

> Hi Yukon and Von,
> I found Vert.x MQTT server[1] provides a nice way of implementing MQTT
> broker functionality. I just played around and created a simple mqtt broker
> with it. The repo is on github[2]  and I have uploaded a short screencast
> to the google drive[3]. I used MQTTLens[4] as the MQTT client here. Thank
> you
>
> [1] http://vertx.io/docs/vertx-mqtt-server/java/
> [2] https://github.com/sudaraka94/mqtt-broker-test
> [3] https://drive.google.com/open?id=1W4QOCRsONYr4Tl7RSDolqQHnNgRwJQUY
> [4] https://chrome.google.com/webstore/detail/mqttlens/hemoj
> aaeigabkbcookmlgmdigohjobjm
>
> Regards,
> Sudaraka Jayathilaka
> *Undergraduate*
> Department of Computer Science and Engineering
> University of Moratuwa
>
>
> On Tue, Mar 20, 2018 at 12:08 AM, Sudaraka Yasindu <
> sudarakayasi...@gmail.com> wrote:
>
>> Hi Yukon and Von,
>> I found Vert.x MQTT server[1] provides a nice way of implementing MQTT
>> broker functionality. I just played around and created a simple mqtt broker
>> with it. The repo is on github[2]  and I have attached a short screen cast
>> with this email. I used MQTTLens[3] as the MQTT client here. Thank you
>>
>> [1] http://vertx.io/docs/vertx-mqtt-server/java/
>> [2] https://github.com/sudaraka94/mqtt-broker-test
>> [3] https://chrome.google.com/webstore/detail/mqttlens/hemoj
>> aaeigabkbcookmlgmdigohjobjm
>>
>> Regards,
>> Sudaraka Jayathilaka
>> *Undergraduate*
>> Department of Computer Science and Engineering
>> University of Moratuwa
>>
>>
>> On Sat, Mar 17, 2018 at 2:27 PM, yukon <yu...@apache.org> wrote:
>>
>>> Cool, looking forward to your design and reuse code is ok if the license
>>> is compatible with ASF license. More details please refer to
>>> https://www.apache.org/legal/resolved.html
>>> <https://www.apache.org/legal/resolved.html#category-b>
>>>
>>> Sudaraka Yasindu <sudarakayasi...@gmail.com>于2018年3月17日 周六下午3:53写道：
>>>
>>>> Hi Yukon and Von Gosling,
>>>> I read the research paper you mentioned in the thread and got a brief
>>>> idea about the proxy server and its functionalities
>>>>
>>>>
>>>> I figured the proxy server implementation must have mainly two
>>>> components. One component for handling all the functionalities regarding
>>>> the ​MQTT protocol and the other component which is responsible for
>>>> translating messages between RocketMQ message format and MQTT message
>>>> format.
>>>>
>>>> *MQTT Broker*
>>>>
>>>> I found a lot of existing opensource MQTT Broker implementations. I
>>>> found Eclipse Mosquitto easy to work with. In the project I will be able to
>>>> use one of these brokers as references and implement the component myself.
>>>> Will I be able to reuse some of the code from those broker implementations
>>>> ? (If the code licensing permits).
>>>>
>>>> *Protocol Conversion Component*
>>>>
>>>> Message format used in MQTT protocol and RocketMQ are slightly
>>>> different. This component will convert messages in MQTT format to RocketMQ
>>>> component and in the other way too.
>>>>
>>>> This is my current idea regarding the project and I'm reading more
>>>> about Linkerd. Is there anything to be corrected?
>>>>
>>>> Regards,
>>>> Sudaraka Jayathilaka
>>>> *Undergraduate*
>>>> Department of Computer Science and Engineering
>>>> University of Moratuwa
>>>>
>>>>
>>>> On Sat, Mar 17, 2018 at 8:43 AM, Sudaraka Yasindu <
>>>> sudarakayasi...@gmail.com> wrote:
>>>>
>>>>> Hi Yukon,
>>>>> I already found the research paper and I'm studying it. Thank you a
>>>>> lot for the direction. I will soon come up with a brief design for the
>>>>> project.
>>>>>
>>>>> Regards,
>>>>> Sudaraka Jayathilaka
>>>>> *Undergraduate*
>>>>> Department of Computer Science and Engineering
>>>>> University of Moratuwa
>>>>>
>>>>>
>>>>> On Sat, Mar 17, 2018 at 8:33 AM, yukon <

Re: [GSoC][ROCKETMQ-372] Providing a REST Proxy to Support HTTP/2 Protocol

[yukon]

Hi,

Some concepts in Linkerd are very valuable and can be used as a reference.

But, It's ok if you want to use Linkerd directly for some necessary reasons.

Regards

On Mon, Mar 19, 2018 at 10:59 PM, Menuka Warushavithana <
menuka...@cse.mrt.ac.lk> wrote:

> Hi,
> Thanks for the info. Are we going to use Linkerd [1] directly in
> implementing the proxy server, or is it only to be used as a reference?
>
> [1] https://linkerd.io/
> <https://mltrk.io/link/https%3A%2F%2Flinkerd.io%2F/QE9YmLinIw2A3pLINZj4>
>
> Best Regards,
> Menuka
>
> On 19 March 2018 at 07:13, yukon <yu...@apache.org
> <https://mltrk.io/link/mailto%3Ayukon%40apache.org/QE9YmLinIw2A3pLINZj4>>
> wrote:
>
> > Hi, the current protocol is customized, please see:
> >
> > <https://mltrk.io/link/https%3A%2F%2Fgithub.com%2Fapache%
> 2Frocketmq%2Ftree%2Fmaster%2Fremoting%2Fsrc%2Fmain%2Fjava%2Forg%2Fapache%
> 2Frocketmq%2Fremoting%2Fprotocol/QE9YmLinIw2A3pLINZj4>
> > https://github.com/apache/rock
> > <https://mltrk.io/link/https%3A%2F%2Fgithub.com%2Fapache%
> 2Frock/QE9YmLinIw2A3pLINZj4>
> > etmq/tree/master/remoting/src/main/java/org/apache/rocketmq/
> > remoting/protocol
> >
> > On Mon, Mar 19, 2018 at 2:06 AM, Menuka Warushavithana <
> > menuka...@cse.mrt.ac.lk
> > <https://mltrk.io/link/mailto%3Amenuka.14%40cse.mrt.ac.lk/
> QE9YmLinIw2A3pLINZj4>>
> > wrote:
> >
> > > Hi Yukon,
> > > It is mentioned in the JIRA issue [1] that, "So far, RocketMQ uses a
> > > customized communication protocol between client and server which is
> > > efficient but limited". However, I could not find the said method in
> the
> > > documentation. It would be appreciated if you could help me understand
> > the
> > > current communication protocol, please.
> > >
> > >
> > > [1]
> > <https://mltrk.io/link/https%3A%2F%2Fissues.apache.org%
> 2Fjira%2Fbrowse%2FROCKETMQ-372/QE9YmLinIw2A3pLINZj4>
> > https://issues.apache.org/jira
> > <https://mltrk.io/link/https%3A%2F%2Fissues.apache.org%
> 2Fjira/QE9YmLinIw2A3pLINZj4>
> > /browse/ROCKETMQ-372
> > > <
> > <https://mltrk.io/link/https%3A%2F%2Fissues.apache.org%
> 2Fjira%2Fbrowse%2FROCKETMQ-372/QItHTjI9X8newkTsyIw0>
> > https://mltrk.io/link/https%3A%2F%2Fissues.apache.org%2Fjir
> > a%2Fbrowse%2FROCKETMQ-372/QItHTjI9X8newkTsyIw0>
> > >
> > > Best Regards,
> > > Menuka
> > >
> > > On 17 March 2018 at 14:19, Menuka Warushavithana <
> > menuka...@cse.mrt.ac.lk
> > <https://mltrk.io/link/mailto%3Amenuka.14%40cse.mrt.ac.lk/
> QE9YmLinIw2A3pLINZj4>
> > >
> > > wrote:
> > >
> > >> Hi Yukon,
> > >> I will continue the discussion (which was started on JIRA) here. I
> went
> > >> through all examples described in the docs [1] and I'm currently
> > studying
> > >> Linkerd [2] to get an idea of implementing the proxy server.
> > >>
> > >> In the meantime, I would appreciate your ideas on designing the REST
> > APIs
> > >> to produce/consume messages.
> > >>
> > >>
> > >> [1]
> > <https://mltrk.io/link/https%3A%2F%2Frocketmq.apache.org%
> 2Fdocs%2Fquick-start%2F/QE9YmLinIw2A3pLINZj4>
> > https://rocketmq.apache.org/do
> > <https://mltrk.io/link/https%3A%2F%2Frocketmq.apache.org%
> 2Fdo/QE9YmLinIw2A3pLINZj4>
> > cs/quick-start/
> > >> <
> > <https://mltrk.io/link/https%3A%2F%2Frocketmq.apache.org%
> 2Fdocs%2Fquick-start%2F/lFINZX2DO0vBptcSPse6>
> > https://mltrk.io/link/https%3A%2F%2Frocketmq.apache.org%2Fd
> > ocs%2Fquick-start%2F/lFINZX2DO0vBptcSPse6>
> > >> [2] https://linkerd.io/
> > <https://mltrk.io/link/https%3A%2F%2Flinkerd.io%2F/QE9YmLinIw2A3pLINZj4>
> > >> <
> > <https://mltrk.io/link/https%3A%2F%2Flinkerd.io%2F/lFINZX2DO0vBptcSPse6>
> > https://mltrk.io/link/https%3A%2F%2Flinkerd.io%2F/lFINZX2DO0vBptcSPse6>
> > >>
> > >> Thank You,
> > >> --
> > >> Menuka Warushavithana
> > >> Final Year Undergraduate
> > >> Department of Computer Science and Engineering
> > >> University of Moratuwa, Sri Lanka.
> > >> LinkedIn:
> > <https://mltrk.io/link/https%3A%2F%2Fwww.linkedin.com%2Fin%
> 2Fmenukawarushavithana/QE9YmLinIw2A3pLINZj4>
> > https://www.linkedin.com/in/me
> > <https://mltrk.io/link/https%3A%2F%2Fwww.linkedin.com%2Fin%
> 2Fme/QE9YmLinIw2A3pLINZj4>
> > nuk

Re: [GSOC|ROCKETMQ-122] Support Global Ordered Messaging

[yukon]

Hi,

Sorry for the late reply.

As for:

```
I'm looking at the BrokerController and MessageStore implementation and
hooks to understand where the merge logic will best fit.
```

how is it going?

Regards

On Sat, Mar 17, 2018 at 11:30 AM, sowmya s <sowmya9...@gmail.com> wrote:

> Thank you yukon,
>
> I'm done with my coursework for this semester and have more time now to
> improve my proposal.
> I'm looking at the BrokerController and MessageStore implementation and
> hooks to understand where the merge logic will best fit. So far I've looked
> at the codebase from a Producer and Consumer perspective and looked at the
> DefaultMQProducerImpl and  DefaultMQPushConsumerImpl for understanding the
> link between how Producers send and Consumers receive messages.
>
> thanks,
> Sowmya
>
> On Fri, Mar 16, 2018 at 8:07 PM, yukon <yu...@apache.org> wrote:
>
> > Cool, let's focus on it and see whether is there anything can be
> polished.
> >
> > Regards
> >
> > On Fri, Mar 16, 2018 at 11:54 PM, sowmya s <sowmya9...@gmail.com> wrote:
> >
> > > Hey yukon,
> > > I submitted my draft on the summer of code homepage a couple of days
> ago,
> > > also attaching the link here for reference,
> > >
> > > https://docs.google.com/file/d/1nXktUO_TF9-rSHSnGj5z5QZoHzMhosxm/edit?
> > > usp=docslist_api=msword
> > >
> > > Thanks,
> > > Sowmya
> > >
> > > On Thu, Mar 15, 2018 at 2:08 AM yukon <yu...@apache.org> wrote:
> > >
> > > > Hi,
> > > >
> > > > Of course, we can work together to finetune your design draft.
> > > >
> > > > Regards,
> > > > yukon
> > > >
> > > > On Thu, Mar 15, 2018 at 5:33 AM, sowmya s <sowmya9...@gmail.com>
> > wrote:
> > > >
> > > > > Hello, yukon and Von,
> > > > >
> > > > > I've shared my GSOC - 18 draft of the project. I'm looking forward
> to
> > > > > working with all of you to finetune the proposal. I will be
> > allocating
> > > 20
> > > > > hours per week from now to the proposal acceptance phase to address
> > > > > questions and dive deep into any suggestions that you provide.
> > > > > I am really looking forward to work on this project.
> > > > >
> > > > > thanks,
> > > > > Sowmya
> > > > >
> > > > > On Tue, Mar 13, 2018 at 11:47 PM, sowmya s <sowmya9...@gmail.com>
> > > wrote:
> > > > >
> > > > > > Hello yukon,
> > > > > >
> > > > > > Thank you for the inputs. I was able to look at the ~/store and
> > kind
> > > of
> > > > > > understand the storage structure. I also looked at the
> > > > > > DefaultMQProducerImpl and DefaultMQPullConsumerImpl, used in the
> > > > > examples.
> > > > > > Now I understand why you proposed a merge sort like approach for
> > > > > > performing global ordering. Since the proposals are open, I am
> > > > finalizing
> > > > > > my draft and will have it up for review very soon.
> > > > > >
> > > > > > thanks,
> > > > > > Sowmya
> > > > > >
> > > > > > On Fri, Mar 9, 2018 at 7:03 AM, yukon <yu...@apache.org> wrote:
> > > > > >
> > > > > >> Hi Sowmya,
> > > > > >>
> > > > > >> ```
> > > > > >> Also, it would be great if you can at a high level, help me
> > > understand
> > > > > >> how the messages in the message queues are stored before the
> > > consumer
> > > > > reads
> > > > > >> them.
> > > > > >> ```
> > > > > >>
> > > > > >>
> > > > > >>
> > > > > >> As shown in this figure, messages are sent to brokers by
> producer
> > > and
> > > > > >> stored in commit log[1], then messages are dispatched to
> > > ConsumeQueue
> > > > by
> > > > > >> topic, the consumer pulls messages from the queue.
> > > > > >>
> > > > > >> I recommend you run a broker and send/consume some messages,
> then
> > > > check
> > > > > >> out the ~/store directory for details.
> > > > > >>
> > > > >

Re: [GSoC][ROCKETMQ-372] Providing a REST Proxy to Support HTTP/2 Protocol

[yukon]

Hi, the current protocol is customized, please see:
https://github.com/apache/rocketmq/tree/master/remoting/src/main/java/org/apache/rocketmq/remoting/protocol

On Mon, Mar 19, 2018 at 2:06 AM, Menuka Warushavithana <
menuka...@cse.mrt.ac.lk> wrote:

> Hi Yukon,
> It is mentioned in the JIRA issue [1] that, "So far, RocketMQ uses a
> customized communication protocol between client and server which is
> efficient but limited". However, I could not find the said method in the
> documentation. It would be appreciated if you could help me understand the
> current communication protocol, please.
>
>
> [1] https://issues.apache.org/jira/browse/ROCKETMQ-372
> <https://mltrk.io/link/https%3A%2F%2Fissues.apache.org%2Fjira%2Fbrowse%2FROCKETMQ-372/QItHTjI9X8newkTsyIw0>
>
> Best Regards,
> Menuka
>
> On 17 March 2018 at 14:19, Menuka Warushavithana <menuka...@cse.mrt.ac.lk>
> wrote:
>
>> Hi Yukon,
>> I will continue the discussion (which was started on JIRA) here. I went
>> through all examples described in the docs [1] and I'm currently studying
>> Linkerd [2] to get an idea of implementing the proxy server.
>>
>> In the meantime, I would appreciate your ideas on designing the REST APIs
>> to produce/consume messages.
>>
>>
>> [1] https://rocketmq.apache.org/docs/quick-start/
>> <https://mltrk.io/link/https%3A%2F%2Frocketmq.apache.org%2Fdocs%2Fquick-start%2F/lFINZX2DO0vBptcSPse6>
>> [2] https://linkerd.io/
>> <https://mltrk.io/link/https%3A%2F%2Flinkerd.io%2F/lFINZX2DO0vBptcSPse6>
>>
>> Thank You,
>> --
>> Menuka Warushavithana
>> Final Year Undergraduate
>> Department of Computer Science and Engineering
>> University of Moratuwa, Sri Lanka.
>> LinkedIn: https://www.linkedin.com/in/menukawarushavithana
>> <https://mltrk.io/link/https%3A%2F%2Fwww.linkedin.com%2Fin%2Fmenukawarushavithana/lFINZX2DO0vBptcSPse6>
>> GitHub: https://www.github.com/menuka94
>> <https://mltrk.io/link/https%3A%2F%2Fwww.github.com%2Fmenuka94/lFINZX2DO0vBptcSPse6>
>>
>>
>
>
> --
> Menuka Warushavithana
> LinkedIn: https://www.linkedin.com/in/menukawarushavithana
> GitHub: https://www.github.com/menuka94
>
>

Re: 答复: 答复: 答复: [GSOC|ROCKETMQ-123]Support Distributed Transactional Messaging

[yukon]

+ riven

Hi Dexin,

Riven is a very senior engineer in RocketMQ community, especially in
distributed transaction area. He is enthusiastic and will help you finished
the design.

Regards,
yukon

On Fri, Mar 16, 2018 at 10:13 PM, 李 德鑫 <dexi...@outlook.com> wrote:

> Sorry, I forgot to add the link
>
>  https://docs.google.com/document/d/1HGQYPc3YtPga-jATx6whMYS7e11NQ6_
> r3tzC3yl4ulI/edit?usp=sharing
>
> 
> 发件人: 李 德鑫 <dexi...@outlook.com>
> 发送时间: 2018年3月16日 14:11:38
> 收件人: dev@rocketmq.apache.org
> 主题: 答复: 答复: 答复: [GSOC|ROCKETMQ-123]Support Distributed Transactional
> Messaging
>
> Hi yukon
>
> I've wrote a design doc about this topic, please have a look.
>
>
>
> Regards,
> Dexin
>
> 
> 发件人: yukon <yu...@apache.org>
> 发送时间: 2018年3月9日 15:11:01
> 收件人: dev
> 主题: Re: 答复: 答复: [GSOC|ROCKETMQ-123]Support Distributed Transactional
> Messaging
>
> Hi Dexin,
>
> ```
> 1.  Does the transactional messaging need to be "exactly only once"
> delivered?
> ```
>
> Please check out https://issues.apache.org/jira/browse/ROCKETMQ-124
>
> ```
> 2.  Where to store the transaction state? Since the state must be
> persistent and also updated.
> ```
>
> We could reuse the rocketmq-store model to store the transaction state.
>
> And, don't worry about the dirty pages if you follow the rule: Append Only.
>
> Regards,
> yukon
>
>
>
> On Wed, Mar 7, 2018 at 12:11 PM, 李 德鑫 <dexi...@outlook.com> wrote:
>
> > Thank you, Yukon!
> >
> >
> > I still have some question about transactional messaging
> >
> >   1.  Does the transactional messaging need to be "exactly only once"
> > delivered?
> >   2.  Where to store the transaction state? Since the state must be
> > persistent and also updated.
> >
> >
> > About the second question, I've considered about some methods
> >
> >   1.  Inside of the message. But it is said that this would generate lots
> > of dirty pages on the OS.
> >   2.  In a database, especially an SQL database. Since class
> > JDBCTransactionStore already exists. But I want to know whether the DB
> will
> > be the bottleneck of performance or scalability.
> >   3.  Like Kafka, use an internal topic called Transaction log. It will
> > record all the operation about transaction states. And store the latest
> > states in the memory. If a partition crashed, It will read the log to
> > recover. But the recovery would be slow.
> >   4.  Similar to 3, store and the transaction state in the Transaction
> > log. But if there's a lot of transaction message, (I guess)this would be
> > like 1 to generate many dirty pages.
> >
> >
> > Regards,
> > Dexin
> > 
> > 发件人: yukon <yu...@apache.org>
> > 发送时间: 2018年3月5日 12:28:47
> > 收件人: dev
> > 主题: Re: 答复: [GSOC|ROCKETMQ-123]Support Distributed Transactional
> Messaging
> >
> > Hi,
> >
> > The links you mentioned just are interfaces, we should implement these
> > APIs.
> >
> > Regards,
> > yukon
> >
> > On Tue, Feb 27, 2018 at 12:07 PM, 李 德鑫 <dexi...@outlook.com> wrote:
> >
> > > My previous email didn't clarify the question clearly, so I'll try to
> > make
> > > it in detail.
> > >
> > >
> > > In this jira's(https://issues.apache.org/jira/browse/ROCKETMQ-123)
> > > description:
> > >
> > >
> > >
> > >
> > > Implement a TransactionProducer and LocalTransactionChecker, guarantee
> > > message delivery and local transaction operations are atomic.
> > >
> > > The following is the simple transactional messaging flow:
> > >
> > > 1. TransactionProducer sends a half message to the broker. A half
> message
> > > means it's not confirmed and can't be delivered to the consumer.
> > >
> > > 2. TransactionProducer executes the specific local transaction.
> > >
> > > 3. Commit or Rollback the half message according to the status of the
> > > local transaction. A half message will be deleted if it's rollbacked
> and
> > > delivered to the consumer if it's committed.
> > >
> > >
> > >
> > > The 1st step I found in https://github.com/apache/
> > > rocketmq/blob/master/client/src/main/java/org/apache/
> > > rocketmq/client/impl/producer/DefaultMQProducerImpl.java#L964
> > >
> > > The 2nd step I found in https://github.com/apache/
> > > rock

Re: [GSOC][ROCKETMQ-380] Provide a modern and friendly console for RocketMQ

[yukon]

Yeah, it's important to include these feature in our console.

BTW, what's your idea about how to handle user features and operations
features?  Integrate these features in one console with two kinds of
role(user and admin), or provide two independent consoles?

Regards,
yukon

On Mon, Mar 19, 2018 at 4:23 PM, Ahmed Ifhaam <ahmedifha...@gmail.com>
wrote:

> hi yukon,
>
> I've been working on the requirements. When i listed the features available
> in cli admin tool but not in the console i found the following list. I
> would like some feedback on the list before i start next step.
> 1. brokerConfigurationUpdate
> 2. BrokerConsume Stats
> 3. CleanExpiredCQ
> 4. CleanUnusedTopic
> 5. WipeWritePermissions
> 6. updateOrderConf
> 7. UpdateKvConf
> 8. DeleteKVConf
> 9. CheckMsgSendRT
> 10. clusterRT
> 11. CloneGroupOffset
> 12. ResetOffsetByTimeStamp
>
> This is the list which i think i should implement. But i have seen in the
> system labels differ a bit from the *'adminTool'*. Also though i tried the
> tool i may have missed something. In that case i just want to confirm these
> are not already there in the current console and these are the only things
> that are not in the current console.
>
> Thank you
>
> On Sun, Mar 18, 2018 at 8:43 AM, yukon <yu...@apache.org> wrote:
>
> > Hi,
> >
> > Yes, most of the user-related features already exist, but we also need an
> > operations console, more details please refer to our admin client:
> > http://rocketmq.apache.org/docs/cli-admin-tool/
> >
> > Regards
> >
> > On Sun, Mar 18, 2018 at 1:03 AM, Ahmed Ifhaam <ahmedifha...@gmail.com>
> > wrote:
> >
> > > hi yukon,
> > >
> > > I tried the commercial product. There is not much change in both except
> > the
> > > user interface, most of the features are already there, organizing and
> > look
> > > and feel of the commercial one is looking better. Before i draft the
> > design
> > > for my changes, I need to know whether the changes you expect are
> totally
> > > on UI Design ? Or a new feature on analytics kind of thing ?
> > >
> > > Thank you
> > >
> > > On Fri, Mar 16, 2018 at 7:47 AM, yukon <yu...@apache.org> wrote:
> > >
> > > > Hi,
> > > >
> > > > This is a commercial version[1] of apache rocketmq and could be your
> > > > reference.
> > > >
> > > > After trying this console, hope you could draft the design ASAP and
> > then
> > > we
> > > > can discuss based on i.
> > > >
> > > >
> > > > Regards,
> > > > yukon
> > > >
> > > > [1]. https://www.alibabacloud.com/product/mq
> > > >
> > > > On Fri, Mar 16, 2018 at 2:41 AM, Ahmed Ifhaam <
> ahmedifha...@gmail.com>
> > > > wrote:
> > > >
> > > > > Hi yukon,
> > > > >
> > > > > I checked the console and after you asked I have re checked it as
> > > well. I
> > > > > used it with the CLI tool in parallel too.
> > > > > In the requirement specification there was a reference console
> which
> > I
> > > > > mentioned in my earlier mail that I couldn't get it to run. So I'm
> > not
> > > > > exactly clear with the requirements. It would be a great help if
> > > someone
> > > > > can point me to a place where i can find the requirements. As I
> have
> > to
> > > > > prepare the proposal (27th March) please kindly take a look at this
> > > ASAP.
> > > > >
> > > > > Thank you
> > > > >
> > > > > On Fri, Mar 9, 2018 at 9:05 PM, yukon <yu...@apache.org> wrote:
> > > > >
> > > > > > Edit the subject!
> > > > > >
> > > > > > On Fri, Mar 9, 2018 at 10:47 PM, yukon <yu...@apache.org> wrote:
> > > > > >
> > > > > > > Hi,
> > > > > > >
> > > > > > > ```
> > > > > > > The other thing is what are the expected features in the new
> > > console?
> > > > > > > ```
> > > > > > >
> > > > > > > Do you check out the features in the current console[1]?
> > > > > > >
> > > > > > > You may have ideas about the features after trying this console
> > and
> > > > the
> > > > > > > `admin` tool[2], th

Re: [VOTE]: Release Apache RocketMQ 4.3.2 RC1

[yukon]

+1 binding

On Wed, Nov 7, 2018 at 1:37 PM 魏欢  wrote:

> +1
> glad to hear the new release!
>
>
> -- Original --
> From:  "dongeforever";
> Date:  Wed, Nov 7, 2018 01:26 PM
> To:  "dev";
>
> Subject:  Re: [VOTE]: Release Apache RocketMQ 4.3.2 RC1
>
>
> +1 binding
>
>
>
> heng du  于2018年11月7日周三 下午1:04写道：
>
> > Hello RocketMQ Community,
> >
> > This is the vote for 4.3.2 of Apache RocketMQ.
> >
> > This release enhanced some of original features and fixed some bugs,
> > further improved the stability of RocketMQ.
> >
> >
> > The artifacts:
> > https://dist.apache.org/repos/dist/dev/rocketmq/4.3.2-rc1/
> >
> > The staging repo:
> >
> https://repository.apache.org/content/repositories/orgapacherocketmq-1014/
> >
> > Git tag for the release:
> > https://github.com/apache/rocketmq/tree/release-4.3.2
> >
> > Hash for the release tag:
> > ea16180d4f4cd9a47714b3514495a02a93ca2454
> >
> > Release Notes:
> > https://rocketmq.apache.org/release_notes/release-notes-4.3.2/
> >
> > The artifacts have been signed with Key :
> > B1BD9DB653F1B79C742839EA9087A12DD1BC4712, 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
> >

Re: [VOTE] RocketMQ-client-go 1.2.0 Release And Graduation

[yukon]

+1

On Fri, Jan 4, 2019 at 2:15 PM Kevin Wang  wrote:

> +1  Go!
>
>
> > 在 2019年1月4日，下午1:15，Shannon  写道：
> >
> > Hello RocketMQ Community,
> >
> > This is the vote for the 1.2.0 release and the graduation of Apache
> RocketMQ-client-go.
> >
> > Github repo: https://github.com/apache/rocketmq-client-go
> >
> > The version released this time is the first initial golang client of
> rocketmq. It is based on the kernel of the CPP client and uses cgo to
> encapsulate the API Implementation of C. You can import go package with go
> get command.
> > The current version provides the following functions:
> > 1.support reliable synchronous sending of messages;
> > 2.support reliable orderly sending of messages;
> > 3.support reliable push consumption model;
> > 4.support default cluster consumption;
> > 5.support delayed messages;
> > 6.support reliable pull consumption model;
> > 7.support custom message properties;
> > 8.support message Compression.
> > 9.support oneway sending of messages;
> > 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: RIP23: Support gRPC protocol

[yukon]

+1 for this proposal.

Obviously, supporting gRPC could make it easier for RocketMQ contributors
to write multi-Language SDKs. Looking forward to more details of this
proposal.

Regards,
yukon

On Wed, Jun 9, 2021 at 11:10 AM Zhanhui Li  wrote:

> Hi,
> This proposal, in general, is in the right direction that helps RocketMQ
> provide full-fledged SDK for popular languages and platforms. Taking full
> advantage of gRPC does save a lot of effort in terms of serialization and
> RPC tiers. Obviously, this proposal also brings complexities and potential
> compatibility issues.
>
> One of the potential issues is that gRPC does not expose Channel in the
> implementation while RocketMQ processors make heavy use of it, even if both
> of them are built on top of Netty 4.x.  Will this an issue when reuse
> existing code?
>
> Zhanhui Li
>
> On Tue, Jun 8, 2021 at 8:28 PM i yangkun  wrote:
>
> > 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,

Re: RIP 24: Introduce multi-protocol support

[yukon]

Hello, community,

Any further opinions about this RIP?  If not, we would like to propose a
draft of the new protocol spec.

Regards,
yukon

On Tue, Sep 28, 2021 at 8:14 AM vongosling  wrote:

> Subscribe to the dev mailing list before sending emails. Otherwise, emails
> cannot be sent to the community.
>
>
> i yangkun  于2021年9月28日周二 上午8:11写道：
>
> > Status
> > 
> >
> >   *   Current Status: Draft
> >   *   Authors: [aaron-ai](https://github.com/aaron-ai)
> >
> >   *   Shepherds: Zhanhui Li<mailto:lizhan...@apache.org>, Yukon > yu...@apache.org>, duhengforever<mailto:duhengfore...@gmail.com>
> >   *   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? yes.
> >   *   will we add new APIs? no.
> >
> >   *   will we add a new feature? yes.
> >
> > Why should we do that
> >
> >   *   Are there any problems with our current project?
> > Currently, the RocketMQ kernel supports only one transport layer protocol
> > available, aka, Remoting. Despite its simplicity and high performance,
> the
> > remoting protocol has some disadvantages:
> >
> >
> > 1. Lack of formal protocol specification. Remoting is loosely defined,
> > lacking a necessary specification document to describe each protocol
> > detail. This indicates much uncertainty, obstructing community
> developers,
> > from different backgrounds, from building uniformly-behaved SDKs and
> > further raises the bar of participation because they have to read the
> > existing source codebase before understanding the ins and outs.
> >
> > 2. Remoting is built on top of Netty, not every language has a Netty-like
> > library. Languages like C/C++ have to pave a lot of "preparation" to
> stand
> > at the same start-line. It would be awesome for RocketMQ to have gRPC,
> > which provides a unified foundation and concepts. Based on this unified
> > foundation, SDKs of different languages can be built with shared models
> and
> > designs.
> >
> > 3. Remoting builds virtually everything from the ground, including
> > auto-retry, connection-multiplexing, coding/decoding, and more. Note
> these
> > all have been properly defined and implemented in gRPC-like libraries.
> > Further, these common parts bring a significant portion of the SDK
> > complexity, whereas they are already available in gRPC for all mainstream
> > programming languages in the field.
> >
> >   *   What can we benefit from the proposed changes?
> > In the future, RocketMQ is supposed to have multi-protocol support, to
> > embrace new technology trends, service mesh for example, and enhance
> > interoperability among different communities, like gRPC, HTTP, MQTT, etc.
> > So we shall introduce a multi-protocol mechanism and add gRPC as a new
> > supported protocol.
> >
> > As we all know, gRPC is widely adopted, and now is a CNCF incubation
> > project. It has a great yet mature ecosystem, including a number of
> > successful community projects. The gRPC-based protocol will bring us more
> > productive features:
> >
> > 1. Build RocketMQ Client SDK with a unified interface.
> >
> >2. Focus on the logic of RocketMQ itself without much effort on
> the
> > transportation layer.
> >
> >3. The HTTP2-based gRPC protocol makes RocketMQ more accessible to
> > cloud-native ecology.
> >
> > Goals
> >
> >   *   What problem is this proposal designed to solve?
> > Introduce a multi-protocol mechanism and add gRPC as a new supported
> > protocol
> >   *   To what degree should we solve the problem?
> >
> > Support gRPC and Remoting protocol both
> >
> > Non-Goals
> >
> >   *   What problem is this proposal NOT designed to solve?
> > Nothing specific.
> >   *   Are there any limits of this proposal?
> > Nothing specific.
> >
> > Changes
> > 
> > Architecture
> >
> > Nothing specific.
> >
> > 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?
> > Yes, new broker server will support both two protocols
> >   *   Are there deprecated APIs?
> > Nothing specific.
> >
> >   *   How do we do the migration?
> > Nothing specific.
> >
> > Implementation Outline
> >
> > We will implement the proposed changes by two phases.
> >
> > Phase 1
> >
> >   1.  Define the new protocol based on gRPC and reach a consensus in the
> > community.
> >   2.  Implement the gRPC server in the rocketmq kernel
> >
> >   1.  Implement Java SDK based on gRPC protocol
> >
> > Phase 2
> >
> >   1.  Implement multilingual SDK, like CPP, Golang, python, C#, etc.
> >
> >
>
> --
> Best Regards :-)
>

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

[yukon]

Great catch, we will draft a new version of client APIs in few days~

On Wed, Sep 29, 2021 at 4:19 PM dongeforever 
wrote:

> The idea is OK.
> And the same time, it is better to show more details.  Maybe drafting the
> new API interface is a good way to dive deep.
>
> caigy  于2021年9月28日周二 下午5:40写道：
>
> > 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.
> >
> >
>

Re: RIP 24: Introduce multi-protocol support

[yukon]

We have drafted the new rocketmq protocol and APIs,  any feedback is
welcome.

Please refer https://github.com/apache/rocketmq-apis/pull/1/files for more
details.

Regards

On Fri, Oct 1, 2021 at 9:40 AM yukon  wrote:

> Hello, community,
>
> Any further opinions about this RIP?  If not, we would like to propose a
> draft of the new protocol spec.
>
> Regards,
> yukon
>
> On Tue, Sep 28, 2021 at 8:14 AM vongosling  wrote:
>
>> Subscribe to the dev mailing list before sending emails. Otherwise, emails
>> cannot be sent to the community.
>>
>>
>> i yangkun  于2021年9月28日周二 上午8:11写道：
>>
>> > Status
>> > 
>> >
>> >   *   Current Status: Draft
>> >   *   Authors: [aaron-ai](https://github.com/aaron-ai)
>> >
>> >   *   Shepherds: Zhanhui Li<mailto:lizhan...@apache.org>, Yukon> > yu...@apache.org>, duhengforever<mailto:duhengfore...@gmail.com>
>> >   *   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? yes.
>> >   *   will we add new APIs? no.
>> >
>> >   *   will we add a new feature? yes.
>> >
>> > Why should we do that
>> >
>> >   *   Are there any problems with our current project?
>> > Currently, the RocketMQ kernel supports only one transport layer
>> protocol
>> > available, aka, Remoting. Despite its simplicity and high performance,
>> the
>> > remoting protocol has some disadvantages:
>> >
>> >
>> > 1. Lack of formal protocol specification. Remoting is loosely defined,
>> > lacking a necessary specification document to describe each protocol
>> > detail. This indicates much uncertainty, obstructing community
>> developers,
>> > from different backgrounds, from building uniformly-behaved SDKs and
>> > further raises the bar of participation because they have to read the
>> > existing source codebase before understanding the ins and outs.
>> >
>> > 2. Remoting is built on top of Netty, not every language has a
>> Netty-like
>> > library. Languages like C/C++ have to pave a lot of "preparation" to
>> stand
>> > at the same start-line. It would be awesome for RocketMQ to have gRPC,
>> > which provides a unified foundation and concepts. Based on this unified
>> > foundation, SDKs of different languages can be built with shared models
>> and
>> > designs.
>> >
>> > 3. Remoting builds virtually everything from the ground, including
>> > auto-retry, connection-multiplexing, coding/decoding, and more. Note
>> these
>> > all have been properly defined and implemented in gRPC-like libraries.
>> > Further, these common parts bring a significant portion of the SDK
>> > complexity, whereas they are already available in gRPC for all
>> mainstream
>> > programming languages in the field.
>> >
>> >   *   What can we benefit from the proposed changes?
>> > In the future, RocketMQ is supposed to have multi-protocol support, to
>> > embrace new technology trends, service mesh for example, and enhance
>> > interoperability among different communities, like gRPC, HTTP, MQTT,
>> etc.
>> > So we shall introduce a multi-protocol mechanism and add gRPC as a new
>> > supported protocol.
>> >
>> > As we all know, gRPC is widely adopted, and now is a CNCF incubation
>> > project. It has a great yet mature ecosystem, including a number of
>> > successful community projects. The gRPC-based protocol will bring us
>> more
>> > productive features:
>> >
>> > 1. Build RocketMQ Client SDK with a unified interface.
>> >
>> >2. Focus on the logic of RocketMQ itself without much effort on
>> the
>> > transportation layer.
>> >
>> >3. The HTTP2-based gRPC protocol makes RocketMQ more accessible
>> to
>> > cloud-native ecology.
>> >
>> > Goals
>> >
>> >   *   What problem is this proposal designed to solve?
>> > Introduce a multi-protocol mechanism and add gRPC as a new supported
>> > protocol
>> >   *   To what degree should we solve the problem?
>> >
>> > Support gRPC and Remoting protocol both
>> >
>> &

Re: [DISCUSS] Support KV semantic storage

[yukon]

kv can be an effective complement to the message model, the rocketmq with
kv support will provide more lightweight features for our users.

As for the implementation, we actually need more discussion and research to
help us reach a consensus. It would be nice if any community contributor
wants to do some research between the compact topic and the kv way.

On Fri, Sep 24, 2021 at 9:01 PM heng du  wrote:

> 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 
> > > > > >
> > > > > >
> > > > > >- 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 

Re: [DISCUSS][RIP-37] New and unified APIs

[yukon]

+1, and let's start the further discussions on new APIs.

On Mon, Mar 14, 2022 at 10:32 AM aaron ai  wrote:

> Hi, RocketMQ Community,
>
> As discussed in the previous email, we launched a new RIP to establish new
> and unified APIs and it's time to start an email thread to enter the voting
> process.
>
> links:
> https://shimo.im/docs/m5kv92OeRRU8olqX
>
> 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!
>
> On Sat, Mar 12, 2022 at 2:32 PM yuzhou  wrote:
>
> > Thanks, glad to see that weakly typed topic will keep exist.
> >
> > On 2022/03/10 08:01:46 yukon wrote:
> > > Hi,
> > >
> > > A weakly typed topic that supports all kinds of messages has
> > > many advantages, it's easy and flexible, while a strongly typed topic
> > also
> > > has other advantages:
> > >
> > > 1. Reinforce the mind that rocketmq supports many integration patterns
> > > which could simplify the development of business applications.
> > > 2. Fail fast if developers send wrong typed messages to a strongly
> typed
> > > topic.
> > > 3. Developers could arrange their applications by topics of different
> > > types, actually, it's a best practice of rocketmq
> > > 4. RocketMQ has a chance to provide more competitive features for
> > different
> > > topic types separately.
> > >
> > > And, we won't disable the weakly typed topic, from an implementation
> > > perspective, we just add an attribute for the topic to indicate whether
> > > it's a strongly typed topic, and a strongly typed topic can be
> converted
> > to
> > > a weakly typed topic easily.
> > >
> > > Regards,
> > > yukon
> > >
> > > On Mon, Mar 7, 2022 at 2:04 PM aaron ai  wrote:
> > >
> > > > Well, The new design about APIs allows us to focus more on the
> feature
> > > > itself, rather than the underlying implementation.
> > > >
> > > > It seems that topic type creates more limitations to users, actually
> it
> > > > simplifies operation of users, we think it is more friendly to users.
> > > >
> > > > On Mon, Mar 7, 2022 at 10:59 AM yuzhou  wrote:
> > > >
> > > > > Hi, aaron:
> > > > >
> > > > > It is a great improvement, especially for some of features such as
> > the
> > > > new
> > > > > constructor use
> > > > > builder pattern, unified 3 kinds of consumers, unified exception
> > types,
> > > > > transaction API
> > > > > improvement.
> > > > >
> > > > > IMHO, many user scenarios have mixed message types, for example,
> > delay
> > > > and
> > > > > normal
> > > > > message in the same topic, other cases use transaction and normal
> > message
> > > > > in the same
> > > > > topic. Do we have specail reason to split them into defferent
> topics?
> > > > >
> > > > >
> > > > > On 2022/03/06 08:10:55 aaron ai wrote:
> > > > > > Hi, RocketMQ Community：
> > > > > >
> > > > > > Regarding the design of RocketMQ APIs, we have put forward some
> new
> > > > > ideas,
> > > > > > hoping to make the definition of messaging model and behavior
> more
> > > > clear.
> > > > > >
> > > > > > We have written the proposal and you can see it by the link
> below:
> > > > > > https://shimo.im/docs/m5kv92OeRRU8olqX
> > > > > >
> > > > > > Please reply to this email if you have any suggestions.
> > > > > >
> > > > >
> > > >
> > >
> >
>

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

[yukon]

+1 for moving forward.

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: [VOTE] [RIP-39] Support gRPC protocol

[yukon]

+1

On Mon, Mar 14, 2022 at 11:02 AM Zhouxiang Zhan  wrote:

> Hi, RocketMQ Community,
>
> This is the vote for [RIP-39] Support gRPC protocol.
>
> Detailed proposal .
>
> 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.
>
>
> Xiaorui Wang  于2022年3月9日周三 16:48写道：
>
> > OK, I support this RIP.
> >
> > I'm delighted to see more and more RIP this year, which shows that our
> > community is maturing. We look forward to more membersjoin us and become
> > the contributors of RocketMQ.
> >
> > Best regards,
> >
> > Xiaorui Wang 王小瑞
> > Apache RocketMQ PMC chair
> >
> >
> > On Wed, Mar 9, 2022 at 4:32 PM 陈仲良  wrote:
> >
> > > Currently the .NET environment  SDK is very lacking. I hope the new sdk
> > > based on gRPC protocol could solve the problem.
> > >
> >
>

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

[yukon]

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) · GitHub)
>
> ●  Mailing List discussion:
> d

Re: [DISCUSS][RIP-37] New and unified APIs

[yukon]

Hi,

A weakly typed topic that supports all kinds of messages has
many advantages, it's easy and flexible, while a strongly typed topic also
has other advantages:

1. Reinforce the mind that rocketmq supports many integration patterns
which could simplify the development of business applications.
2. Fail fast if developers send wrong typed messages to a strongly typed
topic.
3. Developers could arrange their applications by topics of different
types, actually, it's a best practice of rocketmq
4. RocketMQ has a chance to provide more competitive features for different
topic types separately.

And, we won't disable the weakly typed topic, from an implementation
perspective, we just add an attribute for the topic to indicate whether
it's a strongly typed topic, and a strongly typed topic can be converted to
a weakly typed topic easily.

Regards,
yukon

On Mon, Mar 7, 2022 at 2:04 PM aaron ai  wrote:

> Well, The new design about APIs allows us to focus more on the feature
> itself, rather than the underlying implementation.
>
> It seems that topic type creates more limitations to users, actually it
> simplifies operation of users, we think it is more friendly to users.
>
> On Mon, Mar 7, 2022 at 10:59 AM yuzhou  wrote:
>
> > Hi, aaron:
> >
> > It is a great improvement, especially for some of features such as the
> new
> > constructor use
> > builder pattern, unified 3 kinds of consumers, unified exception types,
> > transaction API
> > improvement.
> >
> > IMHO, many user scenarios have mixed message types, for example, delay
> and
> > normal
> > message in the same topic, other cases use transaction and normal message
> > in the same
> > topic. Do we have specail reason to split them into defferent topics?
> >
> >
> > On 2022/03/06 08:10:55 aaron ai wrote:
> > > Hi, RocketMQ Community：
> > >
> > > Regarding the design of RocketMQ APIs, we have put forward some new
> > ideas,
> > > hoping to make the definition of messaging model and behavior more
> clear.
> > >
> > > We have written the proposal and you can see it by the link below:
> > > https://shimo.im/docs/m5kv92OeRRU8olqX
> > >
> > > Please reply to this email if you have any suggestions.
> > >
> >
>

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

[yukon]

Great, this is an important improvement, could reduce failover
time significantly. I would like to be another shepherd if needed.

Regards,
yukon

On Thu, Feb 24, 2022 at 12:14 PM Rongtong Jin <
jinrongton...@mails.ucas.ac.cn> wrote:

> This is a nice RIP, which can solve the issues of 3207 and 3858
>
> https://github.com/apache/rocketmq/issues/3207
> https://github.com/apache/rocketmq/issues/3858
>
> 老康 422766...@qq.com.INVALID写道：
> > 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: [rocketmq-client-csharp] branch develop created (now 9c5b36e)

[yukon]

Hi Von,

This new client is based on the new gRPC APIs. And, we will start a
discussion in the community soon.

Regards,
yukon

On Mon, Feb 14, 2022 at 8:46 AM vongosling  wrote:

> Hi,
>
> I couldn't find any discussion about csharp client. Do we need to add back
> a discussion to the community? Is it version based on our new Grpc. or say,
> just c++ based. I'd like to see guys feedback :-)
>
>
> -- Forwarded message -
> 发件人： 
> Date: 2022年2月12日周六 15:35
> Subject: [rocketmq-client-csharp] branch develop created (now 9c5b36e)
> To: comm...@rocketmq.apache.org 
>
>
> This is an automated email from the ASF dual-hosted git repository.
>
> lizhanhui pushed a change to branch develop
> in repository
> https://gitbox.apache.org/repos/asf/rocketmq-client-csharp.git
> .
>
>
>   at 9c5b36e  Add instruction on build, test and running examples
>
> No new revisions were added by this update.
>
>
> --
> Best Regards :-)
>

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

[yukon]

+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: [VOTE][RIP-36] Optimize topic routing mechanism

[yukon]

+1 for moving forward.

On Wed, Mar 2, 2022 at 7:42 PM xijiu <422766...@qq.com.invalid> 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: [DISCUSS] RIP-35 queue service framework(QSF)

[yukon]

Is anyone interested in this RIP? Please feel free to express your opinions.

About this RIP, my concern is that QSF encapsulates the details of the
producer/consumer may lead to troubleshooting complicated, although QSF is
simple.

Regards,
yukon

On Tue, Mar 29, 2022 at 1:43 AM Jason.Chen  wrote:

> QSF architecture diagram updated, please see attached.
>
>
>
> -- 原始邮件 --
> *发件人:* "Jason.Chen" ;
> *发送时间:* 2022年3月29日(星期二) 凌晨1:39
> *收件人:* "dev";
> *主题:* re： [DISCUSS] RIP-35 queue service framework(QSF)
>
> QSF architecture diagram updated here:
>
>
>
>
> — 原始邮件 —
> 发件人: “Jason.Chen” chenhua...@foxmail.com
> <http://mailto:chenhua...@foxmail.com>;
> 发送时间: 2022年3月25日(星期五) 晚上11:35
> 收件人: “dev”dev@rocketmq.apache.org <http://mailto:dev@rocketmq.apache.org>;
> 主题: 回复： [DISCUSS] RIP-35 queue service framework(QSF)
>
> Sorry for posting a demo of an old version of QSF, the demo of the
> optimized QSF is as follows:
>
> //message producer
>
> @RestController
> @RequestMapping(“/demo/qsf”)
> @Slf4j
> public class TestController {
>
> @QSFConsumer(topic = "rocketmq_topic_qsf_demo", methodSpecials = {
> @QSFConsumer.ConsumerMethodSpecial(methodName = "testQSFCallback", 
> syncCall = true)
> })
> private QSFDemoService qsfDemoService;
>
> @GetMapping(("/basic"))
> public Map qsfBasic(HttpServletRequest request) {
> Map resultMap = new HashMap<>();
>
> // test QSF basic usage
> qsfDemoService.testQSFBasic(100L, "hello world");
>
> return resultMap;
> }
>
> @GetMapping(("/idem"))
> public Map qsfIdempotency(HttpServletRequest request) {
> Map resultMap = new HashMap<>();
>
> // test QSF idempotency, method with same parameters will be invoked 
> exactly once
> qsfDemoService.testQSFIdempotency(100L, "hello world");
> qsfDemoService.testQSFIdempotency(100L, "hello world");
>
> return resultMap;
> }
>
> }
>
> // message consumer
>
> @QSFProvider(consumerId = “rocketmq_consumer_qsf_demo”, topic =
> “rocketmq_topic_qsf_demo”)
> @Slf4j
> public class QSFDemoServiceImpl implements QSFDemoService {
>
> @Override
> public void testQSFBasic(long id, String name) {
> log.info("in service call: testQSFBasic id:{} name:{}", id, name);
> }
>
> @Override
> @QSFIdempotency(idempotentMethodExecuteTimeout = 1000)
> public void testQSFIdempotency(long id, String name) {
> log.info("in service call: testQSFIdempotency id:{} name:{}", id, name);
> }
>
> }
>
> — 原始邮件 —
> 发件人: “Jason.Chen” chenhua...@foxmail.com
> <http://mailto:chenhua...@foxmail.com>;
> 发送时间: 2022年3月25日(星期五) 晚上9:25
> 收件人: “dev”dev@rocketmq.apache.org <http://mailto:dev@rocketmq.apache.org>;
> 主题: 回复： [DISCUSS] RIP-35 queue service framework(QSF)
>
> — 原始邮件 —
> 发件人: “Jason.Chen” chenhua...@foxmail.com
> <http://mailto:chenhua...@foxmail.com>;
> 发送时间: 2022年3月16日(星期三) 晚上9:39
> 收件人: “dev”dev@rocketmq.apache.org <http://mailto:dev@rocketmq.apache.org>;
> 主题: 回复： [DISCUSS] RIP-35 queue service framework(QSF)
>
> Thanks Reply:)
>
> QSF is a step further than rocketmq-spring. Using QSF, users can get the
> most intuitive experience that is almost identical to that of local method
> calls; moreover, QSF reserves a good extension capability, which can easily
> provide features such as idempotent, eventual consistency and flow control
> and so on.
>
> For a simple usage example of QSF, please see the discussion above :)
>
> — 原始邮件 —
> 发件人: “dev” duhengfore...@apache.org
> <http://mailto:duhengfore...@apache.org>;
> 发送时间: 2022年3月16日(星期三) 晚上8:44
> 收件人: “dev”dev@rocketmq.apache.org <http://mailto:dev@rocketmq.apache.org>;
> 主题: Re: [DISCUSS] RIP-35 queue service framework(QSF)
>
> 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 yu...@apache.org <http://mailto:yu...@apache.org> 于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 chenhua...@foxmail.com
> <http://mailto:chenhua...@foxmail.com> 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
>
&g

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

[yukon]

+1

On Wed, Feb 9, 2022 at 7:39 PM heng du  wrote:

> +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: Re: [VOTE][RIP-29] Optimize RocketMQ NameServer

[yukon]

+1

On Tue, Jan 18, 2022 at 11:45 AM Ze Ni  wrote:

> +1
>
> ShannonDing  于2022年1月18日周二 11:40写道：
>
> > +1
> >
> > 在 2022-01-18 11:13:33，"vongosling"  写道：
> > >+1
> > >
> > >周波  于2022年1月18日周二 10:54写道：
> > >
> > >> +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/
> > >>
> > >
> > >
> > >--
> > >Best Regards :-)
> >
>

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

[yukon]

Great!!!

A big step of the RocketMQ community toward the IoT ecosystem.

On Wed, Jan 26, 2022 at 2:22 PM heng du  wrote:

> 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

[yukon]

+1
Enhance the ability of RocketMQ native HA service.

On Wed, Jan 26, 2022 at 4:20 PM dongeforever 
wrote:

> +1.
> The second-level message, such as scheduled/transactional message, should
> not be bound to the master.
>
> heng du  于2022年1月26日周三 12:54写道：
>
> > 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: [VOTE][RIP-43] Support Timing Messages with Arbitrary Time Delay

[yukon]

+1

On Thu, Jun 30, 2022 at 3:24 PM heng du  wrote:

> +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][RIP-44]Support DLedger Controller

[yukon]

+1

On Thu, Jun 30, 2022 at 3:25 PM heng du  wrote:

> +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
> >
>

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

[yukon]

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 Timing Messages with Arbitrary Time Delay

[yukon]

The long-awaited feature for our community, this RIP will make our timer
message more competitive, and make the new SimpleConsumer API
`changeInvisibleDuration` more flexible.

On Tue, Jun 21, 2022 at 11:42 AM dongeforever 
wrote:

> Good Job.
>
> It will be nice if there are some performance test reports.
>
> 季俊涛 <3160102...@zju.edu.cn> 于2022年6月20日周一 17:28写道：
>
> > Hi, RocketMQ Community:
> >
> > Currently, RocketMQ's delay message feature only supports delayed
> delivery
> > for specific time levels. Such delay message feature(only support
> specific
> > levels of delay time) is no longer enough to support the flexible usage
> of
> > rocketmq. Therefore, we need a delay message feature that supports
> > arbitrary delay time. So I would like to start an email thread to discuss
> > RIP-42 Support Timing Messages with Arbitrary Time Delay.
> >
> > I have written my proposal and you can click on the link below：
> > Google Doc:
> >
> https://docs.google.com/document/d/1D6XWwY39p531c2aVi5HQll9iwzTUNT1haUFHqMoRkT0/edit?usp=sharing
> > Shimo:https://shimo.im/docs/gXqme9PKKpIeD7qo/
> >
> > If you have any questions or suggestions, please reply to this email or
> > comment on the proposal.
> >
> > Thanks
> > Juntao Ji
> >
> >
>

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

[yukon]

+1

On Tue, Jul 12, 2022 at 2:46 PM cserwen  wrote:

> +1
>
> > 在 2022年7月12日，10:19，jinrongtong  写道：
> >
> > 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]Release Apache RocketMQ APIs 2.0.0 RC1

[yukon]

+1 binding

I checked:

1. The signed key can be found in the KEYs file
2. LICENSE is Apache V2, the notice of Protocol Buffers has been added to
the notice of this release.
3. gpg verify ok for both source and binary releases.
4. sha512sum ok for both source and binary releases.

Regards,
yukon



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]Release Apache RocketMQ Client Go Native 2.1.1.

[yukon]

+1, thanks.

On Thu, Jul 28, 2022 at 3:48 PM ShannonDing  wrote:

> +1, as RM of this 2.1.1 version, I has checked all issues in list.
>
> At 2022-07-25 21:15:21, "ShannonDing"  wrote:
> >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][RIP-40] Quickly deploy of Apache Rocketmq Cluster

[yukon]

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: [Discuss] RocketMQ-MQTT 1.0.0 LTS release

[yukon]

+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 :-)
>

Re: [Vote] Release gRPC Java Client for Apache RocketMQ 5.0.1 RC1

[yukon]

+1

On Mon, Aug 29, 2022 at 10:55 AM aaron ai  wrote:

> Hello RocketMQ Community,
>
> This is the vote for 5.0.1 RC1 of Apache RocketMQ client for java.
>
> Apache RocketMQ clients 5.x series follow the specs of rocketmq-apis
> , and are built on top of
> Protocol
> Buffer and gRPC.
>
> The artifact:
>
> https://dist.apache.org/repos/dist/dev/rocketmq/rocketmq-clients/rocketmq-client-java/5.0.1-rc1/
>
> The staging repo for maven:
> https://repository.apache.org/content/repositories/orgapacherocketmq-1097/
>
> Git tag for the release:
> https://github.com/apache/rocketmq-clients/tree/rocketmq-client-java-5.0.1
>
> Hash for the release tag: 62d0deb2acfc7adf827f7d636581b6652b1e3b53
>
> Relate Notes:
>
> https://github.com/apache/rocketmq-clients/releases/tag/rocketmq-client-java-5.0.1
>
> 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: [ANNOUNCE]New Committers of Apache RocketMQ: Zhangheng Huang(hzh0425)

[yukon]

Congrats, Zhangheng

Regards,
yukon

On Thu, Aug 11, 2022 at 10:17 AM Hu Zongtang  wrote:

> Congrats, guys :-)
> 
> 发件人: Xiaorui Wang 
> 发送时间: 2022年8月8日 11:36
> 收件人: dev@rocketmq.apache.org 
> 抄送: us...@rocketmq.apache.org 
> 主题: Re: [ANNOUNCE]New Committers of Apache RocketMQ: Zhangheng
> Huang(hzh0425)
>
> Congratulations to be a member of the RocketMQ community！
> Looking forward to building the community together and developing our
> products a step further！
>
> Best regards,
>
> Xiaorui Wang[#] - Apache RocketMQ PMC chair
> [#] https://github.com/vintagewang
>
>
> On Thu, Aug 4, 2022 at 10:50 PM jinrongtong 
> wrote:
>
> > Hi Apache RocketMQ Community,
> >
> >
> >
> > The Project Management Committee (PMC) for Apache RocketMQ has invited
> > Zhangheng Huang (apache id: hzh0425, github id:hzh0425)
> > to become committers, and we are pleased to announce that he has
> accepted.
> >
> >
> > Congrats, guys :-)
> >
> >
> > Best Wishes,
> > RongtongJin
>

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

[yukon]

Congrats, Xiaojian

Regards,
yukon

On Thu, Aug 11, 2022 at 10:16 AM Hu Zongtang  wrote:

> Congrats, guys :-)
> 
> 发件人: heng du 
> 发送时间: 2022年8月2日 17:44
> 收件人: dev 
> 主题: Re: [ANNOUNCE]New Committers of Apache RocketMQ: Sun Xiaojian(apache
> id: sunxiaojian)
>
> 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 gRPC Client for Apache RocketMQ 5.0.0 RC1

[yukon]

+1

On Tue, Aug 2, 2022 at 8:50 PM aaron ai  wrote:

> The artifacts have been migrated to the path below:
>
> Java:
>
> https://dist.apache.org/repos/dist/dev/rocketmq/rocketmq-clients/rocketmq-client-java/5.0.0-rc1/
> CPP:
>
> https://dist.apache.org/repos/dist/dev/rocketmq/rocketmq-clients/rocketmq-client-cpp/5.0.0-rc1/
>
> lollipop  于2022年8月2日周二 10:44写道：
>
> > +1
> >
> > I checked：
> > [OK ]  Checksums and PGP signatures are valid for source package.
> > [OK ]  License and Notice are correct in source package.
> >
> > On Tue, Aug 2, 2022 at 10:32 AM Zhanhui Li  wrote:
> >
> > > +1
> > >
> > > I checked the license, notice and checksum, GPG signature.
> > >
> > > I also validated compilation instructions of the CPP SDK on a clean
> > docker.
> > >
> > > On Mon, Aug 1, 2022 at 8:39 PM aaron ai  wrote:
> > >
> > > > Hello RocketMQ Community,
> > > >
> > > > This is the vote for 5.0.0 RC1 of Apache RocketMQ clients.
> > > >
> > > > Apache RocketMQ clients 5.x series follow the specs of rocketmq-apis
> > > > , and are built on top of
> > > > Protocol Buffer and gRPC.
> > > >
> > > > The artifacts:
> > > >
> > > >-
> > > >
> > > >Java:
> > > >
> > >
> >
> https://dist.apache.org/repos/dist/dev/rocketmq/rocketmq-client-java/5.0.0-rc1/
> > > >-
> > > >
> > > >CPP:
> > > >
> > >
> >
> https://dist.apache.org/repos/dist/dev/rocketmq/rocketmq-client-cpp/5.0.0-rc1/
> > > >
> > > >
> > > > The staging repo for maven:
> > > >
> > > >
> > > >
> > >
> >
> https://repository.apache.org/content/repositories/orgapacherocketmq-1094/
> > > >
> > > > Git tag for the release:
> > > >
> > > >-
> > > >
> > > >Java:
> > > >
> > >
> >
> https://github.com/apache/rocketmq-clients/tree/rocketmq-client-java-5.0.0
> > > >-
> > > >
> > > >CPP:
> https://github.com/apache/rocketmq-clients/tree/cpp-5.0.0-rc1
> > > >
> > > >
> > > > Hash for the release tag:
> > > >
> > > >-
> > > >
> > > >Java: db031977d2e0a1e0d64e43f3daf10eab080a13ac
> > > >-
> > > >
> > > >CPP: 6fcff3207d292d925d06f44148934b8d79c1ab4a
> > > >
> > > >
> > > > Relate Notes:
> > > >
> > > >-
> > > >
> > > >Java:
> > > >
> > >
> >
> https://github.com/apache/rocketmq-clients/releases/tag/rocketmq-client-java-5.0.0
> > > >-
> > > >
> > > >CPP:
> > > >
> > https://github.com/apache/rocketmq-clients/releases/tag/cpp-5.0.0-rc1
> > > >
> > > >
> > > > 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
> > > >
> > > >
> > > >
> > >
> >
>