You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@rocketmq.apache.org by "Jason.Chen" <ch...@foxmail.com> on 2022/03/16 04:55:54 UTC
[DISCUSS] 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: <relased_version>
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
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.
Re: [DISCUSS] RIP-35 queue service framework(QSF)
Posted by yukon <yu...@apache.org>.
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 <ch...@foxmail.com> wrote:
> QSF architecture diagram updated, please see attached.
>
>
>
> ------------------ 原始邮件 ------------------
> *发件人:* "Jason.Chen" <ch...@foxmail.com>;
> *发送时间:* 2022年3月29日(星期二) 凌晨1:39
> *收件人:* "dev"<de...@rocketmq.apache.org>;
> *主题:* re： [DISCUSS] RIP-35 queue service framework(QSF)
>
> QSF architecture diagram updated here:
>
>
>
>
> ————————— 原始邮件 —————————
> 发件人: “Jason.Chen” chenhuanzu@foxmail.com
> <ht...@foxmail.com>;
> 发送时间: 2022年3月25日(星期五) 晚上11:35
> 收件人: “dev”dev@rocketmq.apache.org <ht...@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<String, String> qsfBasic(HttpServletRequest request) {
> Map<String, String> resultMap = new HashMap<>();
>
> // test QSF basic usage
> qsfDemoService.testQSFBasic(100L, "hello world");
>
> return resultMap;
> }
>
> @GetMapping(("/idem"))
> public Map<String, String> qsfIdempotency(HttpServletRequest request) {
> Map<String, String> 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” chenhuanzu@foxmail.com
> <ht...@foxmail.com>;
> 发送时间: 2022年3月25日(星期五) 晚上9:25
> 收件人: “dev”dev@rocketmq.apache.org <ht...@rocketmq.apache.org>;
> 主题: 回复： [DISCUSS] RIP-35 queue service framework(QSF)
>
> ————————— 原始邮件 —————————
> 发件人: “Jason.Chen” chenhuanzu@foxmail.com
> <ht...@foxmail.com>;
> 发送时间: 2022年3月16日(星期三) 晚上9:39
> 收件人: “dev”dev@rocketmq.apache.org <ht...@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” duhengforever@apache.org
> <ht...@apache.org>;
> 发送时间: 2022年3月16日(星期三) 晚上8:44
> 收件人: “dev”dev@rocketmq.apache.org <ht...@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 yukon@apache.org <ht...@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 chenhuanzu@foxmail.com
> <ht...@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
>
> 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”
> <
> chenhuanzu@foxmail.com>;
> 发送时间: 2022年3月16日(星期三) 中午12:55
> 收件人: ”dev”<de...@rocketmq.apache.org>;
>
> 主题: [DISCUSS] 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: <relased_version>
>
> 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
>
> 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.
>
>
>
re： [DISCUSS] RIP-35 queue service framework(QSF)
Posted by "Jason.Chen" <ch...@foxmail.com>.
QSF architecture diagram updated, please see attached.
------------------ 原始邮件 ------------------
发件人: "Jason.Chen" <chenhuanzu@foxmail.com>;
发送时间: 2022年3月29日(星期二) 凌晨1:39
收件人: "dev"<dev@rocketmq.apache.org>;
主题: re： [DISCUSS] RIP-35 queue service framework(QSF)
QSF architecture diagram updated here:
————————— 原始邮件 —————————
发件人: “Jason.Chen” chenhuanzu@foxmail.com;
发送时间: 2022年3月25日(星期五) 晚上11:35
收件人: “dev”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<String, String> qsfBasic(HttpServletRequest request) { Map<String, String> resultMap = new HashMap<>(); // test QSF basic usage qsfDemoService.testQSFBasic(100L, "hello world"); return resultMap; } @GetMapping(("/idem")) public Map<String, String> qsfIdempotency(HttpServletRequest request) { Map<String, String> 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” chenhuanzu@foxmail.com;
发送时间: 2022年3月25日(星期五) 晚上9:25
收件人: “dev”dev@rocketmq.apache.org;
主题: 回复： [DISCUSS] RIP-35 queue service framework(QSF)
————————— 原始邮件 —————————
发件人: “Jason.Chen” chenhuanzu@foxmail.com;
发送时间: 2022年3月16日(星期三) 晚上9:39
收件人: “dev”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” duhengforever@apache.org;
发送时间: 2022年3月16日(星期三) 晚上8:44
收件人: “dev”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 yukon@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 chenhuanzu@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
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?
Encapsulate mq client API to support method invoking style usage.
The encapsulation is easily extensible, to support
idempotence/eventually consistent/ fluid control extensions and so on.
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?
Add new features to classics mq client.
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”
<
chenhuanzu@foxmail.com>;
发送时间: 2022年3月16日(星期三) 中午12:55
收件人: ”dev”<dev@rocketmq.apache.org>;
主题: [DISCUSS] 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: <relased_version>
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
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.
re： [DISCUSS] RIP-35 queue service framework(QSF)
Posted by "Jason.Chen" <ch...@foxmail.com>.
QSF architecture diagram updated here:
————————— 原始邮件 —————————
发件人: “Jason.Chen” chenhuanzu@foxmail.com;
发送时间: 2022年3月25日(星期五) 晚上11:35
收件人: “dev”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<String, String> qsfBasic(HttpServletRequest request) { Map<String, String> resultMap = new HashMap<>(); // test QSF basic usage qsfDemoService.testQSFBasic(100L, "hello world"); return resultMap; } @GetMapping(("/idem")) public Map<String, String> qsfIdempotency(HttpServletRequest request) { Map<String, String> 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” chenhuanzu@foxmail.com;
发送时间: 2022年3月25日(星期五) 晚上9:25
收件人: “dev”dev@rocketmq.apache.org;
主题: 回复： [DISCUSS] RIP-35 queue service framework(QSF)
————————— 原始邮件 —————————
发件人: “Jason.Chen” chenhuanzu@foxmail.com;
发送时间: 2022年3月16日(星期三) 晚上9:39
收件人: “dev”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” duhengforever@apache.org;
发送时间: 2022年3月16日(星期三) 晚上8:44
收件人: “dev”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 yukon@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 chenhuanzu@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
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?
Encapsulate mq client API to support method invoking style usage.
The encapsulation is easily extensible, to support
idempotence/eventually consistent/ fluid control extensions and so on.
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?
Add new features to classics mq client.
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”
<
chenhuanzu@foxmail.com>;
发送时间: 2022年3月16日(星期三) 中午12:55
收件人: ”dev”<dev@rocketmq.apache.org>;
主题: [DISCUSS] 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: <relased_version>
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
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.
回复： [DISCUSS] RIP-35 queue service framework(QSF)
Posted by "Jason.Chen" <ch...@foxmail.com>.
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<String, String> qsfBasic(HttpServletRequest request) {
Map<String, String> resultMap = new HashMap<>();
// test QSF basic usage
qsfDemoService.testQSFBasic(100L, "hello world");
return resultMap;
}
@GetMapping(("/idem"))
public Map<String, String> qsfIdempotency(HttpServletRequest request) {
Map<String, String> 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" <chenhuanzu@foxmail.com>;
发送时间: 2022年3月25日(星期五) 晚上9:25
收件人: "dev"<dev@rocketmq.apache.org>;
主题: 回复： [DISCUSS] RIP-35 queue service framework(QSF)
------------------ 原始邮件 ------------------
发件人: "Jason.Chen" <chenhuanzu@foxmail.com>;
发送时间: 2022年3月16日(星期三) 晚上9:39
收件人: "dev"<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" <duhengforever@apache.org>;
发送时间: 2022年3月16日(星期三) 晚上8:44
收件人: "dev"<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 <yukon@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 <chenhuanzu@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
> >
> >
> >
> >
> >
> >
> > RIP 35 queue service framework(QSF)
> >
> > Status
> >
> > ●&nbsp; Current State: Proposed
> >
> > ●&nbsp; Authors: booom( booom (jason) · GitHub)
> >
> > ●&nbsp; Shepherds: yukon( zhouxinyu (yukon) · GitHub)
> >
> > ●&nbsp; Mailing List discussion: dev@rocketmq.apache.org
> >
> > ●&nbsp; Pull Request:
> >
> > ●&nbsp; Released:&nbsp;
> >
> > Background &amp; Motivation
> >
> > What do we need to do
> >
> > ●&nbsp; Will we add a new module? Yes.
> >
> > ●&nbsp; Will we add new APIs? No.
> >
> > ●&nbsp; Will we add new feature? Yes.
> >
> > Why should we do that
> >
> > ●&nbsp; 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.
> >
> > ●&nbsp; 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
> >
> > ●&nbsp; 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.
> >
> > ●&nbsp; To what degree should we solve the problem?
> >
> > 100%.
> >
> > Non-Goals
> >
> > ●&nbsp; What problem is this proposal NOT designed to solve?
> >
> > 1. Add new features to classics mq client.
> >
> > 2. Affect compatibility.
> >
> > ●&nbsp; 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?&nbsp;
> >
> >
> > 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
> >
> > ●&nbsp; Method signature changes
> >
> > ○&nbsp; &nbsp; &nbsp; method name
> >
> > ○&nbsp; &nbsp; &nbsp; parameter list
> >
> > ○&nbsp; &nbsp; &nbsp; return value
> >
> > Nothing.
> >
> > ●&nbsp; Method behavior changes
> >
> > Nothing.
> >
> > ●&nbsp; CLI command changes
> >
> > Nothing.
> >
> > ●&nbsp; Log format or content changes
> >
> > Nothing.
> >
> > &nbsp;Compatibility, Deprecation, and Migration Plan
> >
> > ●&nbsp; Are backward and forward compatibility taken into
> > consideration?
> >
> > Yes.
> >
> > ●&nbsp; Are there deprecated APIs?
> >
> > Nothing.
> >
> > ●&nbsp; 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.
> >
> >
> >
> >
> >
> >
> >
> > ------------------&nbsp;原始邮件&nbsp;------------------
> > 发件人:
> > "Jason.Chen"
> > <
> > chenhuanzu@foxmail.com&gt;;
> > 发送时间:&nbsp;2022年3月16日(星期三) 中午12:55
> > 收件人:&nbsp;"dev"<dev@rocketmq.apache.org&gt;;
> >
> > 主题:&nbsp;[DISCUSS] RIP-35 queue service framework(QSF)
> >
> >
> >
> >
> >
> >
> >
> > Status
> >
> > ●&nbsp;&nbsp;&nbsp; &nbsp; Current State: Proposed
> >
> > ●&nbsp;&nbsp;&nbsp; &nbsp; Authors: booom( booom (jason) · GitHub)
> >
> > ●&nbsp;&nbsp;&nbsp; &nbsp; Shepherds: yukon( zhouxinyu (yukon) · GitHub)
> >
> > ●&nbsp;&nbsp;&nbsp; &nbsp; Mailing List discussion:
> > dev@rocketmq.apache.org
> >
> > ●&nbsp;&nbsp;&nbsp; &nbsp; Pull Request:
> >
> > ●&nbsp;&nbsp;&nbsp; &nbsp; Released: <relased_version&gt;
> >
> > Background &amp; Motivation
> >
> > What do we need to do
> >
> > ●&nbsp;&nbsp;&nbsp; &nbsp; Will we add a new module? Yes.
> >
> > ●&nbsp;&nbsp;&nbsp; &nbsp; Will we add new APIs? No.
> >
> > ●&nbsp;&nbsp;&nbsp; &nbsp; Will we add new feature? Yes.
> >
> > Why should we do that
> >
> > ●&nbsp;&nbsp;&nbsp; &nbsp; 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.
> >
> > ●&nbsp;&nbsp;&nbsp; &nbsp; What can we benefit proposed changes?
> >
> > 1.&nbsp;&nbsp; &nbsp; Encapsulate mq client API to support method
> invoking
> > style usage.
> >
> > 2.&nbsp;&nbsp; &nbsp; The encapsulation is easily extensible, to support
> > idempotence/eventually consistent/ fluid control extensions and so on.
> >
> > 3.&nbsp;&nbsp; &nbsp; Isolate the mq client manage code and the business
> > logic code, to help mq users improve their systems’ maintainability.
> >
> > &nbsp;
> >
> > Goals
> >
> > ●&nbsp;&nbsp;&nbsp; &nbsp; 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.
> >
> > ●&nbsp;&nbsp;&nbsp; &nbsp; To what degree should we solve the problem?
> >
> > 100%.
> >
> > Non-Goals
> >
> > ●&nbsp;&nbsp;&nbsp; &nbsp; What problem is this proposal NOT designed to
> > solve?
> >
> > 1.&nbsp;&nbsp; &nbsp; Add new features to classics mq client.
> >
> > 2.&nbsp;&nbsp; &nbsp; Affect compatibility.
> >
> > ●&nbsp;&nbsp;&nbsp; &nbsp; Are there any limits of this proposal?
> >
> > Only QSF(queue service framework) users will benefit.
> >
> > Changes
> >
> > Architecture
> >
> > Interface Design/Change
> >
> > ●&nbsp;&nbsp;&nbsp; &nbsp; Method signature changes
> >
> > ○&nbsp;&nbsp;&nbsp; &nbsp; &nbsp;&nbsp;&nbsp; method name
> >
> > ○&nbsp;&nbsp;&nbsp; &nbsp; &nbsp;&nbsp;&nbsp; parameter list
> >
> > ○&nbsp;&nbsp;&nbsp; &nbsp; &nbsp;&nbsp;&nbsp; return value
> >
> > Nothing.
> >
> > ●&nbsp;&nbsp;&nbsp; &nbsp; Method behavior changes
> >
> > Nothing.
> >
> > ●&nbsp;&nbsp;&nbsp; &nbsp; CLI command changes
> >
> > Nothing.
> >
> > ●&nbsp;&nbsp;&nbsp; &nbsp; Log format or content changes
> >
> > Nothing.
> >
> > &nbsp;Compatibility, Deprecation, and Migration Plan
> >
> > ●&nbsp;&nbsp;&nbsp; &nbsp; Are backward and forward compatibility taken
> > into consideration?
> >
> > Yes.
> >
> > ●&nbsp;&nbsp;&nbsp; &nbsp; Are there deprecated APIs?
> >
> > Nothing.
> >
> > ●&nbsp;&nbsp;&nbsp; &nbsp; 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.
>
回复： [DISCUSS] RIP-35 queue service framework(QSF)
Posted by "Jason.Chen" <ch...@foxmail.com>.
QSF is so convenient, let's take a look at a demo of using QSF to send and receive messages:
//receive message
@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: syncVoid id:{} name:{}", id, name);
}
@Override
public void testQSFIdempotency(long id, String name) {
log.info("in service call: asyncEcho id:{} name:{}", id, name);
}
}
//send message
@RestController
@RequestMapping("/demo")
@Slf4j
public class TestController {
@QSFConsumer(topic = "rocketmq_topic_qsf_demo", methodSpecials = {
@QSFConsumer.ConsumerMethodSpecial(methodName = "asyncEcho", idempotent = true)
})
private QSFDemoService qsfDemoService;
@GetMapping(("/qsf"))
public Map<String, String> qsf(HttpServletRequest request) {
Map<String, String> resultMap = new HashMap<>();
// test QSF basic usage
qsfDemoService.testQSFBasic(100L, "hello world");
// test QSF idempotency, method with same parameters will be invoked exactly once
qsfDemoService.testQSFIdempotency(100L, "hello world");
qsfDemoService.testQSFIdempotency(100L, "hello world");
return resultMap;
}
}
QSF API is non-intrusive, requires minimal information provided by users, and minimizes the chance of making mistakes. It is as convenient to use as method calls, with low development and testing costs, and with QSF team communication is simpler.
————————— 原始邮件 —————————
发件人: “Jason.Chen” chenhuanzu@foxmail.com;
发送时间: 2022年3月16日(星期三) 晚上9:39
收件人: “dev”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” duhengforever@apache.org;
发送时间: 2022年3月16日(星期三) 晚上8:44
收件人: “dev”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 yukon@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 chenhuanzu@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
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?
Encapsulate mq client API to support method invoking style usage.
The encapsulation is easily extensible, to support
idempotence/eventually consistent/ fluid control extensions and so on.
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?
Add new features to classics mq client.
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”
<
chenhuanzu@foxmail.com>;
发送时间: 2022年3月16日(星期三) 中午12:55
收件人: ”dev”<dev@rocketmq.apache.org>;
主题: [DISCUSS] 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: <relased_version>
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
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.
回复： [DISCUSS] RIP-35 queue service framework(QSF)
Posted by "Jason.Chen" <ch...@foxmail.com>.
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" <duhengforever@apache.org>;
发送时间: 2022年3月16日(星期三) 晚上8:44
收件人: "dev"<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 <yukon@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 <chenhuanzu@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
> >
> >
> >
> >
> >
> >
> > RIP 35 queue service framework(QSF)
> >
> > Status
> >
> > ●&nbsp; Current State: Proposed
> >
> > ●&nbsp; Authors: booom( booom (jason) · GitHub)
> >
> > ●&nbsp; Shepherds: yukon( zhouxinyu (yukon) · GitHub)
> >
> > ●&nbsp; Mailing List discussion: dev@rocketmq.apache.org
> >
> > ●&nbsp; Pull Request:
> >
> > ●&nbsp; Released:&nbsp;
> >
> > Background &amp; Motivation
> >
> > What do we need to do
> >
> > ●&nbsp; Will we add a new module? Yes.
> >
> > ●&nbsp; Will we add new APIs? No.
> >
> > ●&nbsp; Will we add new feature? Yes.
> >
> > Why should we do that
> >
> > ●&nbsp; 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.
> >
> > ●&nbsp; 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
> >
> > ●&nbsp; 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.
> >
> > ●&nbsp; To what degree should we solve the problem?
> >
> > 100%.
> >
> > Non-Goals
> >
> > ●&nbsp; What problem is this proposal NOT designed to solve?
> >
> > 1. Add new features to classics mq client.
> >
> > 2. Affect compatibility.
> >
> > ●&nbsp; 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?&nbsp;
> >
> >
> > 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
> >
> > ●&nbsp; Method signature changes
> >
> > ○&nbsp; &nbsp; &nbsp; method name
> >
> > ○&nbsp; &nbsp; &nbsp; parameter list
> >
> > ○&nbsp; &nbsp; &nbsp; return value
> >
> > Nothing.
> >
> > ●&nbsp; Method behavior changes
> >
> > Nothing.
> >
> > ●&nbsp; CLI command changes
> >
> > Nothing.
> >
> > ●&nbsp; Log format or content changes
> >
> > Nothing.
> >
> > &nbsp;Compatibility, Deprecation, and Migration Plan
> >
> > ●&nbsp; Are backward and forward compatibility taken into
> > consideration?
> >
> > Yes.
> >
> > ●&nbsp; Are there deprecated APIs?
> >
> > Nothing.
> >
> > ●&nbsp; 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.
> >
> >
> >
> >
> >
> >
> >
> > ------------------&nbsp;原始邮件&nbsp;------------------
> > 发件人:
> > "Jason.Chen"
> > <
> > chenhuanzu@foxmail.com&gt;;
> > 发送时间:&nbsp;2022年3月16日(星期三) 中午12:55
> > 收件人:&nbsp;"dev"<dev@rocketmq.apache.org&gt;;
> >
> > 主题:&nbsp;[DISCUSS] RIP-35 queue service framework(QSF)
> >
> >
> >
> >
> >
> >
> >
> > Status
> >
> > ●&nbsp;&nbsp;&nbsp; &nbsp; Current State: Proposed
> >
> > ●&nbsp;&nbsp;&nbsp; &nbsp; Authors: booom( booom (jason) · GitHub)
> >
> > ●&nbsp;&nbsp;&nbsp; &nbsp; Shepherds: yukon( zhouxinyu (yukon) · GitHub)
> >
> > ●&nbsp;&nbsp;&nbsp; &nbsp; Mailing List discussion:
> > dev@rocketmq.apache.org
> >
> > ●&nbsp;&nbsp;&nbsp; &nbsp; Pull Request:
> >
> > ●&nbsp;&nbsp;&nbsp; &nbsp; Released: <relased_version&gt;
> >
> > Background &amp; Motivation
> >
> > What do we need to do
> >
> > ●&nbsp;&nbsp;&nbsp; &nbsp; Will we add a new module? Yes.
> >
> > ●&nbsp;&nbsp;&nbsp; &nbsp; Will we add new APIs? No.
> >
> > ●&nbsp;&nbsp;&nbsp; &nbsp; Will we add new feature? Yes.
> >
> > Why should we do that
> >
> > ●&nbsp;&nbsp;&nbsp; &nbsp; 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.
> >
> > ●&nbsp;&nbsp;&nbsp; &nbsp; What can we benefit proposed changes?
> >
> > 1.&nbsp;&nbsp; &nbsp; Encapsulate mq client API to support method
> invoking
> > style usage.
> >
> > 2.&nbsp;&nbsp; &nbsp; The encapsulation is easily extensible, to support
> > idempotence/eventually consistent/ fluid control extensions and so on.
> >
> > 3.&nbsp;&nbsp; &nbsp; Isolate the mq client manage code and the business
> > logic code, to help mq users improve their systems’ maintainability.
> >
> > &nbsp;
> >
> > Goals
> >
> > ●&nbsp;&nbsp;&nbsp; &nbsp; 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.
> >
> > ●&nbsp;&nbsp;&nbsp; &nbsp; To what degree should we solve the problem?
> >
> > 100%.
> >
> > Non-Goals
> >
> > ●&nbsp;&nbsp;&nbsp; &nbsp; What problem is this proposal NOT designed to
> > solve?
> >
> > 1.&nbsp;&nbsp; &nbsp; Add new features to classics mq client.
> >
> > 2.&nbsp;&nbsp; &nbsp; Affect compatibility.
> >
> > ●&nbsp;&nbsp;&nbsp; &nbsp; Are there any limits of this proposal?
> >
> > Only QSF(queue service framework) users will benefit.
> >
> > Changes
> >
> > Architecture
> >
> > Interface Design/Change
> >
> > ●&nbsp;&nbsp;&nbsp; &nbsp; Method signature changes
> >
> > ○&nbsp;&nbsp;&nbsp; &nbsp; &nbsp;&nbsp;&nbsp; method name
> >
> > ○&nbsp;&nbsp;&nbsp; &nbsp; &nbsp;&nbsp;&nbsp; parameter list
> >
> > ○&nbsp;&nbsp;&nbsp; &nbsp; &nbsp;&nbsp;&nbsp; return value
> >
> > Nothing.
> >
> > ●&nbsp;&nbsp;&nbsp; &nbsp; Method behavior changes
> >
> > Nothing.
> >
> > ●&nbsp;&nbsp;&nbsp; &nbsp; CLI command changes
> >
> > Nothing.
> >
> > ●&nbsp;&nbsp;&nbsp; &nbsp; Log format or content changes
> >
> > Nothing.
> >
> > &nbsp;Compatibility, Deprecation, and Migration Plan
> >
> > ●&nbsp;&nbsp;&nbsp; &nbsp; Are backward and forward compatibility taken
> > into consideration?
> >
> > Yes.
> >
> > ●&nbsp;&nbsp;&nbsp; &nbsp; Are there deprecated APIs?
> >
> > Nothing.
> >
> > ●&nbsp;&nbsp;&nbsp; &nbsp; 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.
>
Re: [DISCUSS] RIP-35 queue service framework(QSF)
Posted by heng du <du...@apache.org>.
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> 于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 <ch...@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
> >
> >
> >
> >
> >
> >
> > 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"
> > <
> > chenhuanzu@foxmail.com>;
> > 发送时间: 2022年3月16日(星期三) 中午12:55
> > 收件人: "dev"<dev@rocketmq.apache.org>;
> >
> > 主题: [DISCUSS] 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: <relased_version>
> >
> > 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
> >
> > 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.
>
Re: [DISCUSS] RIP-35 queue service framework(QSF)
Posted by yukon <yu...@apache.org>.
Could you please provide some demos to show how we use QSFProducer/Consumer?
On Wed, Mar 16, 2022 at 6:49 PM Jason.Chen <ch...@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
>
>
>
>
>
>
> 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"
> <
> chenhuanzu@foxmail.com>;
> 发送时间: 2022年3月16日(星期三) 中午12:55
> 收件人: "dev"<dev@rocketmq.apache.org>;
>
> 主题: [DISCUSS] 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: <relased_version>
>
> 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
>
> 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.
回复：[DISCUSS] RIP-35 queue service framework(QSF)
Posted by "Jason.Chen" <ch...@foxmail.com>.
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" <chenhuanzu@foxmail.com>;
发送时间: 2022年3月16日(星期三) 中午12:55
收件人: "dev"<dev@rocketmq.apache.org>;
主题: [DISCUSS] 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: <relased_version>
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
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.