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 <chenhua...@foxmail.com> wrote: > QSF architecture diagram updated, please see attached. > > > > ------------------ 原始邮件 ------------------ > *发件人:* "Jason.Chen" <chenhua...@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” 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<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” 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 > > 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”<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. > > >
