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>;
????????: 2022??3??25??(??????) ????9:25
??????: "dev"<dev@rocketmq.apache.org>;
????: ?????? [DISCUSS] RIP-35 queue service framework(QSF)
------------------ ???????? ------------------
??????:
"Jason.Chen"
<chenhua...@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"
<duhengfore...@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 <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>
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"
>
>
<
> > chenhua...@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.
>
