You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@rocketmq.apache.org by heng du <du...@gmail.com> on 2019/09/06 03:35:50 UTC
[VOTE][RIP-16]RocketMQ RPC(Request-Response model) Support
Hello RocketMQ Community,
This is the vote for the kickoff of RIP-16 RocketMQ Request-Response model
support
RPC is a powerful technique for constructing distributed, client-server
based applications. Many companies use the MQ system to constructing their
service bus, especially in the financial industry. We need to implement an
RPC client based on MQ system ourselves because the MQ system doesn’t
support RPC naturally. In the current version of rocketmq project, producer
client only support to send a message to the broker and cannot wait a
response message replied from the consumer. We wish RocketMQ can provide an
RPC client implement to help developers building their applications
conveniently and effectively.
The vote will be open for at least 72 hours or until a necessary number of
votes are reached.
Please vote accordingly:
[ ] +1 approve
[ ] +0 no opinion
[ ] -1 disapprove with the reason
Thanks,
The Apache RocketMQ Team
heng du <du...@gmail.com> 于2019年9月6日周五 上午11:32写道：
> @wenfeng
>
> Actually, Building RPC based on message queue is a very traditional
> approach, especially in the previous ESB, SOA era. Of course, in today's
> micro-services, there are many benefits to building micro-services based on
> MQ.
>
> For example, at the transport layer level, MQ can provide true
> asynchronous communication for RPC. In terms of visualization, MQ can also
> provide better visibility and make it easier to replay traffic to locate or
> fix issues, which is very important in event-driven architectures. Most
> important of all, direct RPC will make the access relationship between
> services become mesh, but based on MQ, the problem of network mesh calls
> are solved. In many industries, such as the financial industry, it is
> difficult to provide all the network access.
> Moreover, the request-response model can be used to make RocketMQ
> integrate well into various infrastructures. In addition, many of the same
> types of message middleware also provide request-response access methods.
>
> So I think that supporting the request-response model will increase the
> competitiveness of RocketMQ and better expand the usage scenario.
>
>
> wenfeng wang <sx...@gmail.com> 于2019年8月27日周二 下午6:15写道：
>
>> IMO, The most popular scenario of MQ System is that decouple complex
>> distributed system and process message asynchronous. If a user wants low
>> latency or explicit response from downstream, he should use an RPC
>> Framework instead of MQ, like Dubbo, gRPC, etc. so I vote for -1.
>>
>>
>> heng du <du...@gmail.com> 于2019年8月27日周二 下午5:54写道：
>>
>>> Dear Apache RocketMQ Community:
>>>
>>> We would like to propose a RIP[16] about RocketMQ RPC(Request-Response
>>> model) Support. Many companies use the MQ system to constructing their
>>> service bus, especially in the financial industry. We wish RocketMQ can
>>> provide an RPC client implement to help developers building their
>>> applications conveniently and effectively.
>>>
>>>
>>> Status
>>>
>>> Current State: Proposed
>>>
>>> Authors: qqeasonchen
>>>
>>> Shepherds: duhengforever
>>>
>>> Mailing List discussion: dev, users
>>>
>>> Pull Request: none
>>>
>>> Released: 4.6.0
>>>
>>> Background & Motivation
>>>
>>> RPC is a powerful technique for constructing distributed, client-server
>>> based applications. Many companies use the MQ system to constructing their
>>> service bus, especially in the financial industry. We need to implement an
>>> RPC client based on MQ system ourselves because the MQ system doesn’t
>>> support RPC naturally. In the current version of rocketmq project, producer
>>> client only support to send a message to the broker and cannot wait a
>>> response message replied from the consumer. We wish RocketMQ can provide an
>>> RPC client implement to help developers building their applications
>>> conveniently and effectively.
>>>
>>> Goals
>>>
>>> - What problem is this proposal designed to solve?
>>>
>>> (1) Design and implement an RPC interface based on RocketMQ Producer,
>>> which support send a message and then wait a response message replied from
>>> the consumer.
>>>
>>> (2) Design and Implement a consumer which can automatically or manually
>>> send a reply message.
>>>
>>> (3) Enable the broker to push a message to an explicit producer.
>>>
>>>
>>>
>>> - To what degree should we solve the problem?
>>>
>>> We wish developers can use RocketMQ easily to constructing their
>>> distributed applications which need RPC call.
>>>
>>> Non-Goals
>>>
>>> - What problem is this proposal NOT designed to solve?
>>>
>>> In this phase, this rip only supports a usable RPC call in most common
>>> scenarios.
>>>
>>> - Are there any limits to this proposal?
>>>
>>> Users may need to tune some client and broker’s configurations to
>>> achieve better performance.
>>>
>>> Changes
>>>
>>> Architecture
>>>
>>> We plan to add RPC implement into client and broker modules. In client
>>> modules, we will add an RPC interface into DefaultMQProducer, and add reply
>>> logic into DefaultMQPushConsumer. In broker modules, we will add a
>>> processor to push reply message from consumer to explicit producer.
>>>
>>> Interface Design/Change
>>>
>>> - Method signature changes
>>>
>>> Plan to add interfaces as follow:
>>>
>>>
>>> Message request(final Message msg, final long timeout) throws MQClientException, RemotingException, MQBrokerException, InterruptedException;
>>>
>>>
>>>
>>> Message request(final Message msg, final SendCallback sendCallback,
>>> final long timeout) throws MQClientException, RemotingException,
>>> InterruptedException;
>>>
>>>
>>>
>>> Message request(final Message msg, final MessageQueueSelector selector,
>>> final Object arg, final long timeout) throws MQClientException,
>>> RemotingException, MQBrokerException, InterruptedException;
>>>
>>>
>>>
>>> Message request(final Message msg, final MessageQueueSelector selector,
>>> final Object arg, final SendCallback sendCallback, final long timeout)
>>> throws MQClientException, RemotingException, InterruptedException;
>>>
>>>
>>>
>>> Message request(final Message msg, final MessageQueue MQ, final long
>>> timeout) throws MQClientException, RemotingException, MQBrokerException,
>>> InterruptedException;
>>>
>>>
>>>
>>> Message request(final Message msg, final MessageQueue mq, final
>>> SendCallback sendCallback, long timeout) throws MQClientException,
>>> RemotingException, InterruptedException;
>>>
>>>
>>>
>>> - Method behavior changes
>>>
>>> No issue
>>>
>>> - CLI command changes
>>>
>>> No issue
>>>
>>> - Log format or content changes
>>>
>>> No issue
>>>
>>> Compatibility, Deprecation, and Migration Plan
>>>
>>> - No issue
>>>
>>> Implementation Outline
>>>
>>> We will implement the proposed changes by *1* phase.
>>>
>>> Phase 1
>>>
>>> 1. Implement RPC feature in Producer
>>> 2. Implement RPC feature in Consumer
>>> 3. Implement RPC feature in Broker
>>>
>>>
[RESULT][VOTE][RIP-16]RocketMQ RPC(Request-Response model) Support
Posted by heng du <du...@gmail.com>.
Hello RocketMQ Community,
This is the vote result for the kickoff of RIP-16 Apache RocketMQ
Request-Response support, and it has been passed with [4] binding +1s,
[3] non-binding
+1s and no 0 or -1:
*Binding votes +1s:*
*heng du *(*duhengforever*)
* liqipeng*(willqipeng)
*Lei Ding*(*shannonDing*)
Gosling Von(vongosling)
*Non-binding votes +1s:*
王金
wenfeng wang
superheizai
This RIP will be accepted and its status will be updated to RocketMQ Wiki
soon.
Thanks,
The Apache RocketMQ Team
heng du <du...@gmail.com> 于2019年9月9日周一 下午2:41写道：
> +1
>
> liqipeng <wl...@163.com> 于2019年9月9日周一 下午2:28写道：
>
>> +1
>> > 在 2019年9月6日，上午11:35，heng du <du...@gmail.com> 写道：
>> >
>> > Hello RocketMQ Community,
>> >
>> > This is the vote for the kickoff of RIP-16 RocketMQ Request-Response
>> model
>> > support
>> >
>> > RPC is a powerful technique for constructing distributed, client-server
>> > based applications. Many companies use the MQ system to constructing
>> their
>> > service bus, especially in the financial industry. We need to implement
>> an
>> > RPC client based on MQ system ourselves because the MQ system doesn’t
>> > support RPC naturally. In the current version of rocketmq project,
>> producer
>> > client only support to send a message to the broker and cannot wait a
>> > response message replied from the consumer. We wish RocketMQ can
>> provide an
>> > RPC client implement to help developers building their applications
>> > conveniently and effectively.
>> >
>> >
>> > The vote will be open for at least 72 hours or until a necessary number
>> of
>> > votes are reached.
>> >
>> > Please vote accordingly:
>> >
>> > [ ] +1 approve
>> > [ ] +0 no opinion
>> > [ ] -1 disapprove with the reason
>> >
>> >
>> > Thanks,
>> > The Apache RocketMQ Team
>> >
>> > heng du <du...@gmail.com> 于2019年9月6日周五 上午11:32写道：
>> >
>> >> @wenfeng
>> >>
>> >> Actually, Building RPC based on message queue is a very traditional
>> >> approach, especially in the previous ESB, SOA era. Of course, in
>> today's
>> >> micro-services, there are many benefits to building micro-services
>> based on
>> >> MQ.
>> >>
>> >> For example, at the transport layer level, MQ can provide true
>> >> asynchronous communication for RPC. In terms of visualization, MQ can
>> also
>> >> provide better visibility and make it easier to replay traffic to
>> locate or
>> >> fix issues, which is very important in event-driven architectures. Most
>> >> important of all, direct RPC will make the access relationship between
>> >> services become mesh, but based on MQ, the problem of network mesh
>> calls
>> >> are solved. In many industries, such as the financial industry, it is
>> >> difficult to provide all the network access.
>> >> Moreover, the request-response model can be used to make RocketMQ
>> >> integrate well into various infrastructures. In addition, many of the
>> same
>> >> types of message middleware also provide request-response access
>> methods.
>> >>
>> >> So I think that supporting the request-response model will increase the
>> >> competitiveness of RocketMQ and better expand the usage scenario.
>> >>
>> >>
>> >> wenfeng wang <sx...@gmail.com> 于2019年8月27日周二 下午6:15写道：
>> >>
>> >>> IMO, The most popular scenario of MQ System is that decouple complex
>> >>> distributed system and process message asynchronous. If a user wants
>> low
>> >>> latency or explicit response from downstream, he should use an RPC
>> >>> Framework instead of MQ, like Dubbo, gRPC, etc. so I vote for -1.
>> >>>
>> >>>
>> >>> heng du <du...@gmail.com> 于2019年8月27日周二 下午5:54写道：
>> >>>
>> >>>> Dear Apache RocketMQ Community:
>> >>>>
>> >>>> We would like to propose a RIP[16] about RocketMQ
>> RPC(Request-Response
>> >>>> model) Support. Many companies use the MQ system to constructing
>> their
>> >>>> service bus, especially in the financial industry. We wish RocketMQ
>> can
>> >>>> provide an RPC client implement to help developers building their
>> >>>> applications conveniently and effectively.
>> >>>>
>> >>>>
>> >>>> Status
>> >>>>
>> >>>> Current State: Proposed
>> >>>>
>> >>>> Authors: qqeasonchen
>> >>>>
>> >>>> Shepherds: duhengforever
>> >>>>
>> >>>> Mailing List discussion: dev, users
>> >>>>
>> >>>> Pull Request: none
>> >>>>
>> >>>> Released: 4.6.0
>> >>>>
>> >>>> Background & Motivation
>> >>>>
>> >>>> RPC is a powerful technique for constructing distributed,
>> client-server
>> >>>> based applications. Many companies use the MQ system to constructing
>> their
>> >>>> service bus, especially in the financial industry. We need to
>> implement an
>> >>>> RPC client based on MQ system ourselves because the MQ system doesn’t
>> >>>> support RPC naturally. In the current version of rocketmq project,
>> producer
>> >>>> client only support to send a message to the broker and cannot wait a
>> >>>> response message replied from the consumer. We wish RocketMQ can
>> provide an
>> >>>> RPC client implement to help developers building their applications
>> >>>> conveniently and effectively.
>> >>>>
>> >>>> Goals
>> >>>>
>> >>>> - What problem is this proposal designed to solve?
>> >>>>
>> >>>> (1) Design and implement an RPC interface based on RocketMQ Producer,
>> >>>> which support send a message and then wait a response message
>> replied from
>> >>>> the consumer.
>> >>>>
>> >>>> (2) Design and Implement a consumer which can automatically or
>> manually
>> >>>> send a reply message.
>> >>>>
>> >>>> (3) Enable the broker to push a message to an explicit producer.
>> >>>>
>> >>>>
>> >>>>
>> >>>> - To what degree should we solve the problem?
>> >>>>
>> >>>> We wish developers can use RocketMQ easily to constructing their
>> >>>> distributed applications which need RPC call.
>> >>>>
>> >>>> Non-Goals
>> >>>>
>> >>>> - What problem is this proposal NOT designed to solve?
>> >>>>
>> >>>> In this phase, this rip only supports a usable RPC call in most
>> common
>> >>>> scenarios.
>> >>>>
>> >>>> - Are there any limits to this proposal?
>> >>>>
>> >>>> Users may need to tune some client and broker’s configurations to
>> >>>> achieve better performance.
>> >>>>
>> >>>> Changes
>> >>>>
>> >>>> Architecture
>> >>>>
>> >>>> We plan to add RPC implement into client and broker modules. In
>> client
>> >>>> modules, we will add an RPC interface into DefaultMQProducer, and
>> add reply
>> >>>> logic into DefaultMQPushConsumer. In broker modules, we will add a
>> >>>> processor to push reply message from consumer to explicit producer.
>> >>>>
>> >>>> Interface Design/Change
>> >>>>
>> >>>> - Method signature changes
>> >>>>
>> >>>> Plan to add interfaces as follow:
>> >>>>
>> >>>>
>> >>>> Message request(final Message msg, final long timeout) throws
>> MQClientException, RemotingException, MQBrokerException,
>> InterruptedException;
>> >>>>
>> >>>>
>> >>>>
>> >>>> Message request(final Message msg, final SendCallback sendCallback,
>> >>>> final long timeout) throws MQClientException, RemotingException,
>> >>>> InterruptedException;
>> >>>>
>> >>>>
>> >>>>
>> >>>> Message request(final Message msg, final MessageQueueSelector
>> selector,
>> >>>> final Object arg, final long timeout) throws MQClientException,
>> >>>> RemotingException, MQBrokerException, InterruptedException;
>> >>>>
>> >>>>
>> >>>>
>> >>>> Message request(final Message msg, final MessageQueueSelector
>> selector,
>> >>>> final Object arg, final SendCallback sendCallback, final long
>> timeout)
>> >>>> throws MQClientException, RemotingException, InterruptedException;
>> >>>>
>> >>>>
>> >>>>
>> >>>> Message request(final Message msg, final MessageQueue MQ, final long
>> >>>> timeout) throws MQClientException, RemotingException,
>> MQBrokerException,
>> >>>> InterruptedException;
>> >>>>
>> >>>>
>> >>>>
>> >>>> Message request(final Message msg, final MessageQueue mq, final
>> >>>> SendCallback sendCallback, long timeout) throws MQClientException,
>> >>>> RemotingException, InterruptedException;
>> >>>>
>> >>>>
>> >>>>
>> >>>> - Method behavior changes
>> >>>>
>> >>>> No issue
>> >>>>
>> >>>> - CLI command changes
>> >>>>
>> >>>> No issue
>> >>>>
>> >>>> - Log format or content changes
>> >>>>
>> >>>> No issue
>> >>>>
>> >>>> Compatibility, Deprecation, and Migration Plan
>> >>>>
>> >>>> - No issue
>> >>>>
>> >>>> Implementation Outline
>> >>>>
>> >>>> We will implement the proposed changes by *1* phase.
>> >>>>
>> >>>> Phase 1
>> >>>>
>> >>>> 1. Implement RPC feature in Producer
>> >>>> 2. Implement RPC feature in Consumer
>> >>>> 3. Implement RPC feature in Broker
>> >>>>
>> >>>>
>>
>>
>>
[RESULT][VOTE][RIP-16]RocketMQ RPC(Request-Response model) Support
Posted by heng du <du...@gmail.com>.
Hello RocketMQ Community,
This is the vote result for the kickoff of RIP-16 Apache RocketMQ
Request-Response support, and it has been passed with [4] binding +1s,
[3] non-binding
+1s and no 0 or -1:
*Binding votes +1s:*
*heng du *(*duhengforever*)
* liqipeng*(willqipeng)
*Lei Ding*(*shannonDing*)
Gosling Von(vongosling)
*Non-binding votes +1s:*
王金
wenfeng wang
superheizai
This RIP will be accepted and its status will be updated to RocketMQ Wiki
soon.
Thanks,
The Apache RocketMQ Team
heng du <du...@gmail.com> 于2019年9月9日周一 下午2:41写道：
> +1
>
> liqipeng <wl...@163.com> 于2019年9月9日周一 下午2:28写道：
>
>> +1
>> > 在 2019年9月6日，上午11:35，heng du <du...@gmail.com> 写道：
>> >
>> > Hello RocketMQ Community,
>> >
>> > This is the vote for the kickoff of RIP-16 RocketMQ Request-Response
>> model
>> > support
>> >
>> > RPC is a powerful technique for constructing distributed, client-server
>> > based applications. Many companies use the MQ system to constructing
>> their
>> > service bus, especially in the financial industry. We need to implement
>> an
>> > RPC client based on MQ system ourselves because the MQ system doesn’t
>> > support RPC naturally. In the current version of rocketmq project,
>> producer
>> > client only support to send a message to the broker and cannot wait a
>> > response message replied from the consumer. We wish RocketMQ can
>> provide an
>> > RPC client implement to help developers building their applications
>> > conveniently and effectively.
>> >
>> >
>> > The vote will be open for at least 72 hours or until a necessary number
>> of
>> > votes are reached.
>> >
>> > Please vote accordingly:
>> >
>> > [ ] +1 approve
>> > [ ] +0 no opinion
>> > [ ] -1 disapprove with the reason
>> >
>> >
>> > Thanks,
>> > The Apache RocketMQ Team
>> >
>> > heng du <du...@gmail.com> 于2019年9月6日周五 上午11:32写道：
>> >
>> >> @wenfeng
>> >>
>> >> Actually, Building RPC based on message queue is a very traditional
>> >> approach, especially in the previous ESB, SOA era. Of course, in
>> today's
>> >> micro-services, there are many benefits to building micro-services
>> based on
>> >> MQ.
>> >>
>> >> For example, at the transport layer level, MQ can provide true
>> >> asynchronous communication for RPC. In terms of visualization, MQ can
>> also
>> >> provide better visibility and make it easier to replay traffic to
>> locate or
>> >> fix issues, which is very important in event-driven architectures. Most
>> >> important of all, direct RPC will make the access relationship between
>> >> services become mesh, but based on MQ, the problem of network mesh
>> calls
>> >> are solved. In many industries, such as the financial industry, it is
>> >> difficult to provide all the network access.
>> >> Moreover, the request-response model can be used to make RocketMQ
>> >> integrate well into various infrastructures. In addition, many of the
>> same
>> >> types of message middleware also provide request-response access
>> methods.
>> >>
>> >> So I think that supporting the request-response model will increase the
>> >> competitiveness of RocketMQ and better expand the usage scenario.
>> >>
>> >>
>> >> wenfeng wang <sx...@gmail.com> 于2019年8月27日周二 下午6:15写道：
>> >>
>> >>> IMO, The most popular scenario of MQ System is that decouple complex
>> >>> distributed system and process message asynchronous. If a user wants
>> low
>> >>> latency or explicit response from downstream, he should use an RPC
>> >>> Framework instead of MQ, like Dubbo, gRPC, etc. so I vote for -1.
>> >>>
>> >>>
>> >>> heng du <du...@gmail.com> 于2019年8月27日周二 下午5:54写道：
>> >>>
>> >>>> Dear Apache RocketMQ Community:
>> >>>>
>> >>>> We would like to propose a RIP[16] about RocketMQ
>> RPC(Request-Response
>> >>>> model) Support. Many companies use the MQ system to constructing
>> their
>> >>>> service bus, especially in the financial industry. We wish RocketMQ
>> can
>> >>>> provide an RPC client implement to help developers building their
>> >>>> applications conveniently and effectively.
>> >>>>
>> >>>>
>> >>>> Status
>> >>>>
>> >>>> Current State: Proposed
>> >>>>
>> >>>> Authors: qqeasonchen
>> >>>>
>> >>>> Shepherds: duhengforever
>> >>>>
>> >>>> Mailing List discussion: dev, users
>> >>>>
>> >>>> Pull Request: none
>> >>>>
>> >>>> Released: 4.6.0
>> >>>>
>> >>>> Background & Motivation
>> >>>>
>> >>>> RPC is a powerful technique for constructing distributed,
>> client-server
>> >>>> based applications. Many companies use the MQ system to constructing
>> their
>> >>>> service bus, especially in the financial industry. We need to
>> implement an
>> >>>> RPC client based on MQ system ourselves because the MQ system doesn’t
>> >>>> support RPC naturally. In the current version of rocketmq project,
>> producer
>> >>>> client only support to send a message to the broker and cannot wait a
>> >>>> response message replied from the consumer. We wish RocketMQ can
>> provide an
>> >>>> RPC client implement to help developers building their applications
>> >>>> conveniently and effectively.
>> >>>>
>> >>>> Goals
>> >>>>
>> >>>> - What problem is this proposal designed to solve?
>> >>>>
>> >>>> (1) Design and implement an RPC interface based on RocketMQ Producer,
>> >>>> which support send a message and then wait a response message
>> replied from
>> >>>> the consumer.
>> >>>>
>> >>>> (2) Design and Implement a consumer which can automatically or
>> manually
>> >>>> send a reply message.
>> >>>>
>> >>>> (3) Enable the broker to push a message to an explicit producer.
>> >>>>
>> >>>>
>> >>>>
>> >>>> - To what degree should we solve the problem?
>> >>>>
>> >>>> We wish developers can use RocketMQ easily to constructing their
>> >>>> distributed applications which need RPC call.
>> >>>>
>> >>>> Non-Goals
>> >>>>
>> >>>> - What problem is this proposal NOT designed to solve?
>> >>>>
>> >>>> In this phase, this rip only supports a usable RPC call in most
>> common
>> >>>> scenarios.
>> >>>>
>> >>>> - Are there any limits to this proposal?
>> >>>>
>> >>>> Users may need to tune some client and broker’s configurations to
>> >>>> achieve better performance.
>> >>>>
>> >>>> Changes
>> >>>>
>> >>>> Architecture
>> >>>>
>> >>>> We plan to add RPC implement into client and broker modules. In
>> client
>> >>>> modules, we will add an RPC interface into DefaultMQProducer, and
>> add reply
>> >>>> logic into DefaultMQPushConsumer. In broker modules, we will add a
>> >>>> processor to push reply message from consumer to explicit producer.
>> >>>>
>> >>>> Interface Design/Change
>> >>>>
>> >>>> - Method signature changes
>> >>>>
>> >>>> Plan to add interfaces as follow:
>> >>>>
>> >>>>
>> >>>> Message request(final Message msg, final long timeout) throws
>> MQClientException, RemotingException, MQBrokerException,
>> InterruptedException;
>> >>>>
>> >>>>
>> >>>>
>> >>>> Message request(final Message msg, final SendCallback sendCallback,
>> >>>> final long timeout) throws MQClientException, RemotingException,
>> >>>> InterruptedException;
>> >>>>
>> >>>>
>> >>>>
>> >>>> Message request(final Message msg, final MessageQueueSelector
>> selector,
>> >>>> final Object arg, final long timeout) throws MQClientException,
>> >>>> RemotingException, MQBrokerException, InterruptedException;
>> >>>>
>> >>>>
>> >>>>
>> >>>> Message request(final Message msg, final MessageQueueSelector
>> selector,
>> >>>> final Object arg, final SendCallback sendCallback, final long
>> timeout)
>> >>>> throws MQClientException, RemotingException, InterruptedException;
>> >>>>
>> >>>>
>> >>>>
>> >>>> Message request(final Message msg, final MessageQueue MQ, final long
>> >>>> timeout) throws MQClientException, RemotingException,
>> MQBrokerException,
>> >>>> InterruptedException;
>> >>>>
>> >>>>
>> >>>>
>> >>>> Message request(final Message msg, final MessageQueue mq, final
>> >>>> SendCallback sendCallback, long timeout) throws MQClientException,
>> >>>> RemotingException, InterruptedException;
>> >>>>
>> >>>>
>> >>>>
>> >>>> - Method behavior changes
>> >>>>
>> >>>> No issue
>> >>>>
>> >>>> - CLI command changes
>> >>>>
>> >>>> No issue
>> >>>>
>> >>>> - Log format or content changes
>> >>>>
>> >>>> No issue
>> >>>>
>> >>>> Compatibility, Deprecation, and Migration Plan
>> >>>>
>> >>>> - No issue
>> >>>>
>> >>>> Implementation Outline
>> >>>>
>> >>>> We will implement the proposed changes by *1* phase.
>> >>>>
>> >>>> Phase 1
>> >>>>
>> >>>> 1. Implement RPC feature in Producer
>> >>>> 2. Implement RPC feature in Consumer
>> >>>> 3. Implement RPC feature in Broker
>> >>>>
>> >>>>
>>
>>
>>
Re: [VOTE][RIP-16]RocketMQ RPC(Request-Response model) Support
Posted by heng du <du...@gmail.com>.
+1
liqipeng <wl...@163.com> 于2019年9月9日周一 下午2:28写道：
> +1
> > 在 2019年9月6日，上午11:35，heng du <du...@gmail.com> 写道：
> >
> > Hello RocketMQ Community,
> >
> > This is the vote for the kickoff of RIP-16 RocketMQ Request-Response
> model
> > support
> >
> > RPC is a powerful technique for constructing distributed, client-server
> > based applications. Many companies use the MQ system to constructing
> their
> > service bus, especially in the financial industry. We need to implement
> an
> > RPC client based on MQ system ourselves because the MQ system doesn’t
> > support RPC naturally. In the current version of rocketmq project,
> producer
> > client only support to send a message to the broker and cannot wait a
> > response message replied from the consumer. We wish RocketMQ can provide
> an
> > RPC client implement to help developers building their applications
> > conveniently and effectively.
> >
> >
> > The vote will be open for at least 72 hours or until a necessary number
> of
> > votes are reached.
> >
> > Please vote accordingly:
> >
> > [ ] +1 approve
> > [ ] +0 no opinion
> > [ ] -1 disapprove with the reason
> >
> >
> > Thanks,
> > The Apache RocketMQ Team
> >
> > heng du <du...@gmail.com> 于2019年9月6日周五 上午11:32写道：
> >
> >> @wenfeng
> >>
> >> Actually, Building RPC based on message queue is a very traditional
> >> approach, especially in the previous ESB, SOA era. Of course, in today's
> >> micro-services, there are many benefits to building micro-services
> based on
> >> MQ.
> >>
> >> For example, at the transport layer level, MQ can provide true
> >> asynchronous communication for RPC. In terms of visualization, MQ can
> also
> >> provide better visibility and make it easier to replay traffic to
> locate or
> >> fix issues, which is very important in event-driven architectures. Most
> >> important of all, direct RPC will make the access relationship between
> >> services become mesh, but based on MQ, the problem of network mesh calls
> >> are solved. In many industries, such as the financial industry, it is
> >> difficult to provide all the network access.
> >> Moreover, the request-response model can be used to make RocketMQ
> >> integrate well into various infrastructures. In addition, many of the
> same
> >> types of message middleware also provide request-response access
> methods.
> >>
> >> So I think that supporting the request-response model will increase the
> >> competitiveness of RocketMQ and better expand the usage scenario.
> >>
> >>
> >> wenfeng wang <sx...@gmail.com> 于2019年8月27日周二 下午6:15写道：
> >>
> >>> IMO, The most popular scenario of MQ System is that decouple complex
> >>> distributed system and process message asynchronous. If a user wants
> low
> >>> latency or explicit response from downstream, he should use an RPC
> >>> Framework instead of MQ, like Dubbo, gRPC, etc. so I vote for -1.
> >>>
> >>>
> >>> heng du <du...@gmail.com> 于2019年8月27日周二 下午5:54写道：
> >>>
> >>>> Dear Apache RocketMQ Community:
> >>>>
> >>>> We would like to propose a RIP[16] about RocketMQ RPC(Request-Response
> >>>> model) Support. Many companies use the MQ system to constructing their
> >>>> service bus, especially in the financial industry. We wish RocketMQ
> can
> >>>> provide an RPC client implement to help developers building their
> >>>> applications conveniently and effectively.
> >>>>
> >>>>
> >>>> Status
> >>>>
> >>>> Current State: Proposed
> >>>>
> >>>> Authors: qqeasonchen
> >>>>
> >>>> Shepherds: duhengforever
> >>>>
> >>>> Mailing List discussion: dev, users
> >>>>
> >>>> Pull Request: none
> >>>>
> >>>> Released: 4.6.0
> >>>>
> >>>> Background & Motivation
> >>>>
> >>>> RPC is a powerful technique for constructing distributed,
> client-server
> >>>> based applications. Many companies use the MQ system to constructing
> their
> >>>> service bus, especially in the financial industry. We need to
> implement an
> >>>> RPC client based on MQ system ourselves because the MQ system doesn’t
> >>>> support RPC naturally. In the current version of rocketmq project,
> producer
> >>>> client only support to send a message to the broker and cannot wait a
> >>>> response message replied from the consumer. We wish RocketMQ can
> provide an
> >>>> RPC client implement to help developers building their applications
> >>>> conveniently and effectively.
> >>>>
> >>>> Goals
> >>>>
> >>>> - What problem is this proposal designed to solve?
> >>>>
> >>>> (1) Design and implement an RPC interface based on RocketMQ Producer,
> >>>> which support send a message and then wait a response message replied
> from
> >>>> the consumer.
> >>>>
> >>>> (2) Design and Implement a consumer which can automatically or
> manually
> >>>> send a reply message.
> >>>>
> >>>> (3) Enable the broker to push a message to an explicit producer.
> >>>>
> >>>>
> >>>>
> >>>> - To what degree should we solve the problem?
> >>>>
> >>>> We wish developers can use RocketMQ easily to constructing their
> >>>> distributed applications which need RPC call.
> >>>>
> >>>> Non-Goals
> >>>>
> >>>> - What problem is this proposal NOT designed to solve?
> >>>>
> >>>> In this phase, this rip only supports a usable RPC call in most common
> >>>> scenarios.
> >>>>
> >>>> - Are there any limits to this proposal?
> >>>>
> >>>> Users may need to tune some client and broker’s configurations to
> >>>> achieve better performance.
> >>>>
> >>>> Changes
> >>>>
> >>>> Architecture
> >>>>
> >>>> We plan to add RPC implement into client and broker modules. In client
> >>>> modules, we will add an RPC interface into DefaultMQProducer, and add
> reply
> >>>> logic into DefaultMQPushConsumer. In broker modules, we will add a
> >>>> processor to push reply message from consumer to explicit producer.
> >>>>
> >>>> Interface Design/Change
> >>>>
> >>>> - Method signature changes
> >>>>
> >>>> Plan to add interfaces as follow:
> >>>>
> >>>>
> >>>> Message request(final Message msg, final long timeout) throws
> MQClientException, RemotingException, MQBrokerException,
> InterruptedException;
> >>>>
> >>>>
> >>>>
> >>>> Message request(final Message msg, final SendCallback sendCallback,
> >>>> final long timeout) throws MQClientException, RemotingException,
> >>>> InterruptedException;
> >>>>
> >>>>
> >>>>
> >>>> Message request(final Message msg, final MessageQueueSelector
> selector,
> >>>> final Object arg, final long timeout) throws MQClientException,
> >>>> RemotingException, MQBrokerException, InterruptedException;
> >>>>
> >>>>
> >>>>
> >>>> Message request(final Message msg, final MessageQueueSelector
> selector,
> >>>> final Object arg, final SendCallback sendCallback, final long timeout)
> >>>> throws MQClientException, RemotingException, InterruptedException;
> >>>>
> >>>>
> >>>>
> >>>> Message request(final Message msg, final MessageQueue MQ, final long
> >>>> timeout) throws MQClientException, RemotingException,
> MQBrokerException,
> >>>> InterruptedException;
> >>>>
> >>>>
> >>>>
> >>>> Message request(final Message msg, final MessageQueue mq, final
> >>>> SendCallback sendCallback, long timeout) throws MQClientException,
> >>>> RemotingException, InterruptedException;
> >>>>
> >>>>
> >>>>
> >>>> - Method behavior changes
> >>>>
> >>>> No issue
> >>>>
> >>>> - CLI command changes
> >>>>
> >>>> No issue
> >>>>
> >>>> - Log format or content changes
> >>>>
> >>>> No issue
> >>>>
> >>>> Compatibility, Deprecation, and Migration Plan
> >>>>
> >>>> - No issue
> >>>>
> >>>> Implementation Outline
> >>>>
> >>>> We will implement the proposed changes by *1* phase.
> >>>>
> >>>> Phase 1
> >>>>
> >>>> 1. Implement RPC feature in Producer
> >>>> 2. Implement RPC feature in Consumer
> >>>> 3. Implement RPC feature in Broker
> >>>>
> >>>>
>
>
>
Re: [VOTE][RIP-16]RocketMQ RPC(Request-Response model) Support
Posted by heng du <du...@gmail.com>.
+1
liqipeng <wl...@163.com> 于2019年9月9日周一 下午2:28写道：
> +1
> > 在 2019年9月6日，上午11:35，heng du <du...@gmail.com> 写道：
> >
> > Hello RocketMQ Community,
> >
> > This is the vote for the kickoff of RIP-16 RocketMQ Request-Response
> model
> > support
> >
> > RPC is a powerful technique for constructing distributed, client-server
> > based applications. Many companies use the MQ system to constructing
> their
> > service bus, especially in the financial industry. We need to implement
> an
> > RPC client based on MQ system ourselves because the MQ system doesn’t
> > support RPC naturally. In the current version of rocketmq project,
> producer
> > client only support to send a message to the broker and cannot wait a
> > response message replied from the consumer. We wish RocketMQ can provide
> an
> > RPC client implement to help developers building their applications
> > conveniently and effectively.
> >
> >
> > The vote will be open for at least 72 hours or until a necessary number
> of
> > votes are reached.
> >
> > Please vote accordingly:
> >
> > [ ] +1 approve
> > [ ] +0 no opinion
> > [ ] -1 disapprove with the reason
> >
> >
> > Thanks,
> > The Apache RocketMQ Team
> >
> > heng du <du...@gmail.com> 于2019年9月6日周五 上午11:32写道：
> >
> >> @wenfeng
> >>
> >> Actually, Building RPC based on message queue is a very traditional
> >> approach, especially in the previous ESB, SOA era. Of course, in today's
> >> micro-services, there are many benefits to building micro-services
> based on
> >> MQ.
> >>
> >> For example, at the transport layer level, MQ can provide true
> >> asynchronous communication for RPC. In terms of visualization, MQ can
> also
> >> provide better visibility and make it easier to replay traffic to
> locate or
> >> fix issues, which is very important in event-driven architectures. Most
> >> important of all, direct RPC will make the access relationship between
> >> services become mesh, but based on MQ, the problem of network mesh calls
> >> are solved. In many industries, such as the financial industry, it is
> >> difficult to provide all the network access.
> >> Moreover, the request-response model can be used to make RocketMQ
> >> integrate well into various infrastructures. In addition, many of the
> same
> >> types of message middleware also provide request-response access
> methods.
> >>
> >> So I think that supporting the request-response model will increase the
> >> competitiveness of RocketMQ and better expand the usage scenario.
> >>
> >>
> >> wenfeng wang <sx...@gmail.com> 于2019年8月27日周二 下午6:15写道：
> >>
> >>> IMO, The most popular scenario of MQ System is that decouple complex
> >>> distributed system and process message asynchronous. If a user wants
> low
> >>> latency or explicit response from downstream, he should use an RPC
> >>> Framework instead of MQ, like Dubbo, gRPC, etc. so I vote for -1.
> >>>
> >>>
> >>> heng du <du...@gmail.com> 于2019年8月27日周二 下午5:54写道：
> >>>
> >>>> Dear Apache RocketMQ Community:
> >>>>
> >>>> We would like to propose a RIP[16] about RocketMQ RPC(Request-Response
> >>>> model) Support. Many companies use the MQ system to constructing their
> >>>> service bus, especially in the financial industry. We wish RocketMQ
> can
> >>>> provide an RPC client implement to help developers building their
> >>>> applications conveniently and effectively.
> >>>>
> >>>>
> >>>> Status
> >>>>
> >>>> Current State: Proposed
> >>>>
> >>>> Authors: qqeasonchen
> >>>>
> >>>> Shepherds: duhengforever
> >>>>
> >>>> Mailing List discussion: dev, users
> >>>>
> >>>> Pull Request: none
> >>>>
> >>>> Released: 4.6.0
> >>>>
> >>>> Background & Motivation
> >>>>
> >>>> RPC is a powerful technique for constructing distributed,
> client-server
> >>>> based applications. Many companies use the MQ system to constructing
> their
> >>>> service bus, especially in the financial industry. We need to
> implement an
> >>>> RPC client based on MQ system ourselves because the MQ system doesn’t
> >>>> support RPC naturally. In the current version of rocketmq project,
> producer
> >>>> client only support to send a message to the broker and cannot wait a
> >>>> response message replied from the consumer. We wish RocketMQ can
> provide an
> >>>> RPC client implement to help developers building their applications
> >>>> conveniently and effectively.
> >>>>
> >>>> Goals
> >>>>
> >>>> - What problem is this proposal designed to solve?
> >>>>
> >>>> (1) Design and implement an RPC interface based on RocketMQ Producer,
> >>>> which support send a message and then wait a response message replied
> from
> >>>> the consumer.
> >>>>
> >>>> (2) Design and Implement a consumer which can automatically or
> manually
> >>>> send a reply message.
> >>>>
> >>>> (3) Enable the broker to push a message to an explicit producer.
> >>>>
> >>>>
> >>>>
> >>>> - To what degree should we solve the problem?
> >>>>
> >>>> We wish developers can use RocketMQ easily to constructing their
> >>>> distributed applications which need RPC call.
> >>>>
> >>>> Non-Goals
> >>>>
> >>>> - What problem is this proposal NOT designed to solve?
> >>>>
> >>>> In this phase, this rip only supports a usable RPC call in most common
> >>>> scenarios.
> >>>>
> >>>> - Are there any limits to this proposal?
> >>>>
> >>>> Users may need to tune some client and broker’s configurations to
> >>>> achieve better performance.
> >>>>
> >>>> Changes
> >>>>
> >>>> Architecture
> >>>>
> >>>> We plan to add RPC implement into client and broker modules. In client
> >>>> modules, we will add an RPC interface into DefaultMQProducer, and add
> reply
> >>>> logic into DefaultMQPushConsumer. In broker modules, we will add a
> >>>> processor to push reply message from consumer to explicit producer.
> >>>>
> >>>> Interface Design/Change
> >>>>
> >>>> - Method signature changes
> >>>>
> >>>> Plan to add interfaces as follow:
> >>>>
> >>>>
> >>>> Message request(final Message msg, final long timeout) throws
> MQClientException, RemotingException, MQBrokerException,
> InterruptedException;
> >>>>
> >>>>
> >>>>
> >>>> Message request(final Message msg, final SendCallback sendCallback,
> >>>> final long timeout) throws MQClientException, RemotingException,
> >>>> InterruptedException;
> >>>>
> >>>>
> >>>>
> >>>> Message request(final Message msg, final MessageQueueSelector
> selector,
> >>>> final Object arg, final long timeout) throws MQClientException,
> >>>> RemotingException, MQBrokerException, InterruptedException;
> >>>>
> >>>>
> >>>>
> >>>> Message request(final Message msg, final MessageQueueSelector
> selector,
> >>>> final Object arg, final SendCallback sendCallback, final long timeout)
> >>>> throws MQClientException, RemotingException, InterruptedException;
> >>>>
> >>>>
> >>>>
> >>>> Message request(final Message msg, final MessageQueue MQ, final long
> >>>> timeout) throws MQClientException, RemotingException,
> MQBrokerException,
> >>>> InterruptedException;
> >>>>
> >>>>
> >>>>
> >>>> Message request(final Message msg, final MessageQueue mq, final
> >>>> SendCallback sendCallback, long timeout) throws MQClientException,
> >>>> RemotingException, InterruptedException;
> >>>>
> >>>>
> >>>>
> >>>> - Method behavior changes
> >>>>
> >>>> No issue
> >>>>
> >>>> - CLI command changes
> >>>>
> >>>> No issue
> >>>>
> >>>> - Log format or content changes
> >>>>
> >>>> No issue
> >>>>
> >>>> Compatibility, Deprecation, and Migration Plan
> >>>>
> >>>> - No issue
> >>>>
> >>>> Implementation Outline
> >>>>
> >>>> We will implement the proposed changes by *1* phase.
> >>>>
> >>>> Phase 1
> >>>>
> >>>> 1. Implement RPC feature in Producer
> >>>> 2. Implement RPC feature in Consumer
> >>>> 3. Implement RPC feature in Broker
> >>>>
> >>>>
>
>
>
Re: [VOTE][RIP-16]RocketMQ RPC(Request-Response model) Support
Posted by liqipeng <wl...@163.com>.
+1
> 在 2019年9月6日，上午11:35，heng du <du...@gmail.com> 写道：
>
> Hello RocketMQ Community,
>
> This is the vote for the kickoff of RIP-16 RocketMQ Request-Response model
> support
>
> RPC is a powerful technique for constructing distributed, client-server
> based applications. Many companies use the MQ system to constructing their
> service bus, especially in the financial industry. We need to implement an
> RPC client based on MQ system ourselves because the MQ system doesn’t
> support RPC naturally. In the current version of rocketmq project, producer
> client only support to send a message to the broker and cannot wait a
> response message replied from the consumer. We wish RocketMQ can provide an
> RPC client implement to help developers building their applications
> conveniently and effectively.
>
>
> The vote will be open for at least 72 hours or until a necessary number of
> votes are reached.
>
> Please vote accordingly:
>
> [ ] +1 approve
> [ ] +0 no opinion
> [ ] -1 disapprove with the reason
>
>
> Thanks,
> The Apache RocketMQ Team
>
> heng du <du...@gmail.com> 于2019年9月6日周五 上午11:32写道：
>
>> @wenfeng
>>
>> Actually, Building RPC based on message queue is a very traditional
>> approach, especially in the previous ESB, SOA era. Of course, in today's
>> micro-services, there are many benefits to building micro-services based on
>> MQ.
>>
>> For example, at the transport layer level, MQ can provide true
>> asynchronous communication for RPC. In terms of visualization, MQ can also
>> provide better visibility and make it easier to replay traffic to locate or
>> fix issues, which is very important in event-driven architectures. Most
>> important of all, direct RPC will make the access relationship between
>> services become mesh, but based on MQ, the problem of network mesh calls
>> are solved. In many industries, such as the financial industry, it is
>> difficult to provide all the network access.
>> Moreover, the request-response model can be used to make RocketMQ
>> integrate well into various infrastructures. In addition, many of the same
>> types of message middleware also provide request-response access methods.
>>
>> So I think that supporting the request-response model will increase the
>> competitiveness of RocketMQ and better expand the usage scenario.
>>
>>
>> wenfeng wang <sx...@gmail.com> 于2019年8月27日周二 下午6:15写道：
>>
>>> IMO, The most popular scenario of MQ System is that decouple complex
>>> distributed system and process message asynchronous. If a user wants low
>>> latency or explicit response from downstream, he should use an RPC
>>> Framework instead of MQ, like Dubbo, gRPC, etc. so I vote for -1.
>>>
>>>
>>> heng du <du...@gmail.com> 于2019年8月27日周二 下午5:54写道：
>>>
>>>> Dear Apache RocketMQ Community:
>>>>
>>>> We would like to propose a RIP[16] about RocketMQ RPC(Request-Response
>>>> model) Support. Many companies use the MQ system to constructing their
>>>> service bus, especially in the financial industry. We wish RocketMQ can
>>>> provide an RPC client implement to help developers building their
>>>> applications conveniently and effectively.
>>>>
>>>>
>>>> Status
>>>>
>>>> Current State: Proposed
>>>>
>>>> Authors: qqeasonchen
>>>>
>>>> Shepherds: duhengforever
>>>>
>>>> Mailing List discussion: dev, users
>>>>
>>>> Pull Request: none
>>>>
>>>> Released: 4.6.0
>>>>
>>>> Background & Motivation
>>>>
>>>> RPC is a powerful technique for constructing distributed, client-server
>>>> based applications. Many companies use the MQ system to constructing their
>>>> service bus, especially in the financial industry. We need to implement an
>>>> RPC client based on MQ system ourselves because the MQ system doesn’t
>>>> support RPC naturally. In the current version of rocketmq project, producer
>>>> client only support to send a message to the broker and cannot wait a
>>>> response message replied from the consumer. We wish RocketMQ can provide an
>>>> RPC client implement to help developers building their applications
>>>> conveniently and effectively.
>>>>
>>>> Goals
>>>>
>>>> - What problem is this proposal designed to solve?
>>>>
>>>> (1) Design and implement an RPC interface based on RocketMQ Producer,
>>>> which support send a message and then wait a response message replied from
>>>> the consumer.
>>>>
>>>> (2) Design and Implement a consumer which can automatically or manually
>>>> send a reply message.
>>>>
>>>> (3) Enable the broker to push a message to an explicit producer.
>>>>
>>>>
>>>>
>>>> - To what degree should we solve the problem?
>>>>
>>>> We wish developers can use RocketMQ easily to constructing their
>>>> distributed applications which need RPC call.
>>>>
>>>> Non-Goals
>>>>
>>>> - What problem is this proposal NOT designed to solve?
>>>>
>>>> In this phase, this rip only supports a usable RPC call in most common
>>>> scenarios.
>>>>
>>>> - Are there any limits to this proposal?
>>>>
>>>> Users may need to tune some client and broker’s configurations to
>>>> achieve better performance.
>>>>
>>>> Changes
>>>>
>>>> Architecture
>>>>
>>>> We plan to add RPC implement into client and broker modules. In client
>>>> modules, we will add an RPC interface into DefaultMQProducer, and add reply
>>>> logic into DefaultMQPushConsumer. In broker modules, we will add a
>>>> processor to push reply message from consumer to explicit producer.
>>>>
>>>> Interface Design/Change
>>>>
>>>> - Method signature changes
>>>>
>>>> Plan to add interfaces as follow:
>>>>
>>>>
>>>> Message request(final Message msg, final long timeout) throws MQClientException, RemotingException, MQBrokerException, InterruptedException;
>>>>
>>>>
>>>>
>>>> Message request(final Message msg, final SendCallback sendCallback,
>>>> final long timeout) throws MQClientException, RemotingException,
>>>> InterruptedException;
>>>>
>>>>
>>>>
>>>> Message request(final Message msg, final MessageQueueSelector selector,
>>>> final Object arg, final long timeout) throws MQClientException,
>>>> RemotingException, MQBrokerException, InterruptedException;
>>>>
>>>>
>>>>
>>>> Message request(final Message msg, final MessageQueueSelector selector,
>>>> final Object arg, final SendCallback sendCallback, final long timeout)
>>>> throws MQClientException, RemotingException, InterruptedException;
>>>>
>>>>
>>>>
>>>> Message request(final Message msg, final MessageQueue MQ, final long
>>>> timeout) throws MQClientException, RemotingException, MQBrokerException,
>>>> InterruptedException;
>>>>
>>>>
>>>>
>>>> Message request(final Message msg, final MessageQueue mq, final
>>>> SendCallback sendCallback, long timeout) throws MQClientException,
>>>> RemotingException, InterruptedException;
>>>>
>>>>
>>>>
>>>> - Method behavior changes
>>>>
>>>> No issue
>>>>
>>>> - CLI command changes
>>>>
>>>> No issue
>>>>
>>>> - Log format or content changes
>>>>
>>>> No issue
>>>>
>>>> Compatibility, Deprecation, and Migration Plan
>>>>
>>>> - No issue
>>>>
>>>> Implementation Outline
>>>>
>>>> We will implement the proposed changes by *1* phase.
>>>>
>>>> Phase 1
>>>>
>>>> 1. Implement RPC feature in Producer
>>>> 2. Implement RPC feature in Consumer
>>>> 3. Implement RPC feature in Broker
>>>>
>>>>
Re: [VOTE][RIP-16]RocketMQ RPC(Request-Response model) Support
Posted by 王金 <ru...@163.com>.
+1
> �� 2019��9��6�գ�����8:52��ShannonDing <di...@apache.org> д����
>
>
> +1
>
> On 09/6/2019 11:35��heng du<du...@gmail.com> <ma...@gmail.com> wrote��
> Hello RocketMQ Community,
>
> This is the vote for the kickoff of RIP-16 RocketMQ Request-Response model support
>
> RPC is a powerful technique for constructing distributed, client-server based applications. Many companies use the MQ system to constructing their service bus, especially in the financial industry. We need to implement an RPC client based on MQ system ourselves because the MQ system doesn��t support RPC naturally. In the current version of rocketmq project, producer client only support to send a message to the broker and cannot wait a response message replied from the consumer. We wish RocketMQ can provide an RPC client implement to help developers building their applications conveniently and effectively.
>
>
> The vote will be open for at least 72 hours or until a necessary number of votes are reached.
>
> Please vote accordingly:
>
> [ ] +1 approve
> [ ] +0 no opinion
> [ ] -1 disapprove with the reason
>
>
> Thanks,
> The Apache RocketMQ Team
>
> heng du <duhengforever@gmail.com <ma...@gmail.com>> ��2019��9��6������ ����11:32���
> @wenfeng
>
> Actually, Building RPC based on message queue is a very traditional approach, especially in the previous ESB, SOA era. Of course, in today's micro-services, there are many benefits to building micro-services based on MQ.
>
> For example, at the transport layer level, MQ can provide true asynchronous communication for RPC. In terms of visualization, MQ can also provide better visibility and make it easier to replay traffic to locate or fix issues, which is very important in event-driven architectures. Most important of all, direct RPC will make the access relationship between services become mesh, but based on MQ, the problem of network mesh calls are solved. In many industries, such as the financial industry, it is difficult to provide all the network access.
> Moreover, the request-response model can be used to make RocketMQ integrate well into various infrastructures. In addition, many of the same types of message middleware also provide request-response access methods.
>
> So I think that supporting the request-response model will increase the competitiveness of RocketMQ and better expand the usage scenario.
>
>
> wenfeng wang <sxian.wang@gmail.com <ma...@gmail.com>> ��2019��8��27���ܶ� ����6:15д����
> IMO, The most popular scenario of MQ System is that decouple complex distributed system and process message asynchronous. If a user wants low latency or explicit response from downstream, he should use an RPC Framework instead of MQ, like Dubbo, gRPC, etc. so I vote for -1.
>
>
> heng du <duhengforever@gmail.com <ma...@gmail.com>> ��2019��8��27���ܶ� ����5:54д����
> Dear Apache RocketMQ Community:
>
> We would like to propose a RIP[16] about RocketMQ RPC(Request-Response model) Support. Many companies use the MQ system to constructing their service bus, especially in the financial industry. We wish RocketMQ can provide an RPC client implement to help developers building their applications conveniently and effectively.
>
> Status
> Current State: Proposed
>
> Authors: qqeasonchen
>
> Shepherds: duhengforever
>
> Mailing List discussion: dev, users
>
> Pull Request: none
>
> Released: 4.6.0
>
> Background & Motivation
>
> RPC is a powerful technique for constructing distributed, client-server based applications. Many companies use the MQ system to constructing their service bus, especially in the financial industry. We need to implement an RPC client based on MQ system ourselves because the MQ system doesn��t support RPC naturally. In the current version of rocketmq project, producer client only support to send a message to the broker and cannot wait a response message replied from the consumer. We wish RocketMQ can provide an RPC client implement to help developers building their applications conveniently and effectively.
>
> Goals
>
> What problem is this proposal designed to solve?
> (1) Design and implement an RPC interface based on RocketMQ Producer, which support send a message and then wait a response message replied from the consumer.
>
> (2) Design and Implement a consumer which can automatically or manually send a reply message.
>
> (3) Enable the broker to push a message to an explicit producer.
>
>
>
> To what degree should we solve the problem?
> We wish developers can use RocketMQ easily to constructing their distributed applications which need RPC call.
>
> Non-Goals
>
> What problem is this proposal NOT designed to solve?
> In this phase, this rip only supports a usable RPC call in most common scenarios.
>
> Are there any limits to this proposal?
> Users may need to tune some client and broker��s configurations to achieve better performance.
>
> Changes
>
> Architecture
>
> We plan to add RPC implement into client and broker modules. In client modules, we will add an RPC interface into DefaultMQProducer, and add reply logic into DefaultMQPushConsumer. In broker modules, we will add a processor to push reply message from consumer to explicit producer.
>
> Interface Design/Change
>
> Method signature changes
> Plan to add interfaces as follow:
>
> Message request(final Message msg, final long timeout) throws MQClientException, RemotingException, MQBrokerException, InterruptedException;
>
>
>
> Message request(final Message msg, final SendCallback sendCallback, final long timeout) throws MQClientException, RemotingException, InterruptedException;
>
>
>
> Message request(final Message msg, final MessageQueueSelector selector, final Object arg, final long timeout) throws MQClientException, RemotingException, MQBrokerException, InterruptedException;
>
>
>
> Message request(final Message msg, final MessageQueueSelector selector, final Object arg, final SendCallback sendCallback, final long timeout) throws MQClientException, RemotingException, InterruptedException;
>
>
>
> Message request(final Message msg, final MessageQueue MQ, final long timeout) throws MQClientException, RemotingException, MQBrokerException, InterruptedException;
>
>
>
> Message request(final Message msg, final MessageQueue mq, final SendCallback sendCallback, long timeout) throws MQClientException, RemotingException, InterruptedException;
>
>
>
> Method behavior changes
> No issue
>
> CLI command changes
> No issue
>
> Log format or content changes
> No issue
>
> Compatibility, Deprecation, and Migration Plan
>
> No issue
> Implementation Outline
>
> We will implement the proposed changes by 1 phase.
>
> Phase 1
>
> Implement RPC feature in Producer
> Implement RPC feature in Consumer
> Implement RPC feature in Broker
Re:[VOTE][RIP-16]RocketMQ RPC(Request-Response model) Support
Posted by ShannonDing <di...@apache.org>.
+1
On 09/6/2019 11:35，heng du<du...@gmail.com> wrote：
Hello RocketMQ Community,
This is the vote for the kickoff of RIP-16 RocketMQ Request-Response model support
RPC is a powerful technique for constructing distributed, client-server based applications. Many companies use the MQ system to constructing their service bus, especially in the financial industry. We need to implement an RPC client based on MQ system ourselves because the MQ system doesn’t support RPC naturally. In the current version of rocketmq project, producer client only support to send a message to the broker and cannot wait a response message replied from the consumer. We wish RocketMQ can provide an RPC client implement to help developers building their applications conveniently and effectively.
The vote will be open for at least 72 hours or until a necessary number of votes are reached.
Please vote accordingly:
[ ] +1 approve
[ ] +0 no opinion
[ ] -1 disapprove with the reason
Thanks,
The Apache RocketMQ Team
heng du <du...@gmail.com> 于2019年9月6日周五 上午11:32写道：
@wenfeng
Actually, Building RPC based on message queue is a very traditional approach, especially in the previous ESB, SOA era. Of course, in today's micro-services, there are many benefits to building micro-services based on MQ.
For example, at the transport layer level, MQ can provide true asynchronous communication for RPC. In terms of visualization, MQ can also provide better visibility and make it easier to replay traffic to locate or fix issues, which is very important in event-driven architectures. Most important of all, direct RPC will make the access relationship between services become mesh, but based on MQ, the problem of network mesh calls are solved. In many industries, such as the financial industry, it is difficult to provide all the network access.
Moreover, the request-response model can be used to make RocketMQ integrate well into various infrastructures. In addition, many of the same types of message middleware also provide request-response access methods.
So I think that supporting the request-response model will increase the competitiveness of RocketMQ and better expand the usage scenario.
wenfeng wang <sx...@gmail.com> 于2019年8月27日周二 下午6:15写道：
IMO, The most popular scenario of MQ System is that decouple complex distributed system and process message asynchronous. If a user wants low latency or explicit response from downstream, he should use an RPC Framework instead of MQ, like Dubbo, gRPC, etc. so I vote for -1.
heng du <du...@gmail.com> 于2019年8月27日周二 下午5:54写道：
Dear Apache RocketMQ Community:
We would like to propose a RIP[16] about RocketMQ RPC(Request-Response model) Support. Many companies use the MQ system to constructing their service bus, especially in the financial industry. We wish RocketMQ can provide an RPC client implement to help developers building their applications conveniently and effectively.
Status
Current State: Proposed
Authors: qqeasonchen
Shepherds: duhengforever
Mailing List discussion: dev, users
Pull Request: none
Released: 4.6.0
Background & Motivation
RPC is a powerful technique for constructing distributed, client-server based applications. Many companies use the MQ system to constructing their service bus, especially in the financial industry. We need to implement an RPC client based on MQ system ourselves because the MQ system doesn’t support RPC naturally. In the current version of rocketmq project, producer client only support to send a message to the broker and cannot wait a response message replied from the consumer. We wish RocketMQ can provide an RPC client implement to help developers building their applications conveniently and effectively.
Goals
What problem is this proposal designed to solve?
(1) Design and implement an RPC interface based on RocketMQ Producer, which support send a message and then wait a response message replied from the consumer.
(2) Design and Implement a consumer which can automatically or manually send a reply message.
(3) Enable the broker to push a message to an explicit producer.
To what degree should we solve the problem?
We wish developers can use RocketMQ easily to constructing their distributed applications which need RPC call.
Non-Goals
What problem is this proposal NOT designed to solve?
In this phase, this rip only supports a usable RPC call in most common scenarios.
Are there any limits to this proposal?
Users may need to tune some client and broker’s configurations to achieve better performance.
Changes
Architecture
We plan to add RPC implement into client and broker modules. In client modules, we will add an RPC interface into DefaultMQProducer, and add reply logic into DefaultMQPushConsumer. In broker modules, we will add a processor to push reply message from consumer to explicit producer.
Interface Design/Change
Method signature changes
Plan to add interfaces as follow:
Message request(final Message msg, final long timeout) throws MQClientException, RemotingException, MQBrokerException, InterruptedException;
Message request(final Message msg, final SendCallback sendCallback, final long timeout) throws MQClientException, RemotingException, InterruptedException;
Message request(final Message msg, final MessageQueueSelector selector, final Object arg, final long timeout) throws MQClientException, RemotingException, MQBrokerException, InterruptedException;
Message request(final Message msg, final MessageQueueSelector selector, final Object arg, final SendCallback sendCallback, final long timeout) throws MQClientException, RemotingException, InterruptedException;
Message request(final Message msg, final MessageQueue MQ, final long timeout) throws MQClientException, RemotingException, MQBrokerException, InterruptedException;
Message request(final Message msg, final MessageQueue mq, final SendCallback sendCallback, long timeout) throws MQClientException, RemotingException, InterruptedException;
Method behavior changes
No issue
CLI command changes
No issue
Log format or content changes
No issue
Compatibility, Deprecation, and Migration Plan
No issue
Implementation Outline
We will implement the proposed changes by 1 phase.
Phase 1
Implement RPC feature in Producer
Implement RPC feature in Consumer
Implement RPC feature in Broker
Re: [VOTE][RIP-16]RocketMQ RPC(Request-Response model) Support
Posted by Gosling Von <fe...@gmail.com>.
+1
Glad to see the strong desire for microservice/servicemesh in community. Let it be native in RocketMQ :-)
Best Regards,
Von Gosling
> On Sep 6, 2019, at 11:35 AM, heng du <du...@gmail.com> wrote:
>
> Hello RocketMQ Community,
>
> This is the vote for the kickoff of RIP-16 RocketMQ Request-Response model support
>
> RPC is a powerful technique for constructing distributed, client-server based applications. Many companies use the MQ system to constructing their service bus, especially in the financial industry. We need to implement an RPC client based on MQ system ourselves because the MQ system doesn’t support RPC naturally. In the current version of rocketmq project, producer client only support to send a message to the broker and cannot wait a response message replied from the consumer. We wish RocketMQ can provide an RPC client implement to help developers building their applications conveniently and effectively.
>
>
> The vote will be open for at least 72 hours or until a necessary number of votes are reached.
>
> Please vote accordingly:
>
> [ ] +1 approve
> [ ] +0 no opinion
> [ ] -1 disapprove with the reason
>
>
> Thanks,
> The Apache RocketMQ Team
>
> heng du <duhengforever@gmail.com <ma...@gmail.com>> 于2019年9月6日周五 上午11:32写道：
> @wenfeng
>
> Actually, Building RPC based on message queue is a very traditional approach, especially in the previous ESB, SOA era. Of course, in today's micro-services, there are many benefits to building micro-services based on MQ.
>
> For example, at the transport layer level, MQ can provide true asynchronous communication for RPC. In terms of visualization, MQ can also provide better visibility and make it easier to replay traffic to locate or fix issues, which is very important in event-driven architectures. Most important of all, direct RPC will make the access relationship between services become mesh, but based on MQ, the problem of network mesh calls are solved. In many industries, such as the financial industry, it is difficult to provide all the network access.
> Moreover, the request-response model can be used to make RocketMQ integrate well into various infrastructures. In addition, many of the same types of message middleware also provide request-response access methods.
>
> So I think that supporting the request-response model will increase the competitiveness of RocketMQ and better expand the usage scenario.
>
>
> wenfeng wang <sxian.wang@gmail.com <ma...@gmail.com>> 于2019年8月27日周二 下午6:15写道：
> IMO, The most popular scenario of MQ System is that decouple complex distributed system and process message asynchronous. If a user wants low latency or explicit response from downstream, he should use an RPC Framework instead of MQ, like Dubbo, gRPC, etc. so I vote for -1.
>
>
> heng du <duhengforever@gmail.com <ma...@gmail.com>> 于2019年8月27日周二 下午5:54写道：
> Dear Apache RocketMQ Community:
>
> We would like to propose a RIP[16] about RocketMQ RPC(Request-Response model) Support. Many companies use the MQ system to constructing their service bus, especially in the financial industry. We wish RocketMQ can provide an RPC client implement to help developers building their applications conveniently and effectively.
>
> Status
> Current State: Proposed
>
> Authors: qqeasonchen
>
> Shepherds: duhengforever
>
> Mailing List discussion: dev, users
>
> Pull Request: none
>
> Released: 4.6.0
>
> Background & Motivation
>
> RPC is a powerful technique for constructing distributed, client-server based applications. Many companies use the MQ system to constructing their service bus, especially in the financial industry. We need to implement an RPC client based on MQ system ourselves because the MQ system doesn’t support RPC naturally. In the current version of rocketmq project, producer client only support to send a message to the broker and cannot wait a response message replied from the consumer. We wish RocketMQ can provide an RPC client implement to help developers building their applications conveniently and effectively.
>
> Goals
>
> What problem is this proposal designed to solve?
> (1) Design and implement an RPC interface based on RocketMQ Producer, which support send a message and then wait a response message replied from the consumer.
>
> (2) Design and Implement a consumer which can automatically or manually send a reply message.
>
> (3) Enable the broker to push a message to an explicit producer.
>
>
>
> To what degree should we solve the problem?
> We wish developers can use RocketMQ easily to constructing their distributed applications which need RPC call.
>
> Non-Goals
>
> What problem is this proposal NOT designed to solve?
> In this phase, this rip only supports a usable RPC call in most common scenarios.
>
> Are there any limits to this proposal?
> Users may need to tune some client and broker’s configurations to achieve better performance.
>
> Changes
>
> Architecture
>
> We plan to add RPC implement into client and broker modules. In client modules, we will add an RPC interface into DefaultMQProducer, and add reply logic into DefaultMQPushConsumer. In broker modules, we will add a processor to push reply message from consumer to explicit producer.
>
> Interface Design/Change
>
> Method signature changes
> Plan to add interfaces as follow:
>
> Message request(final Message msg, final long timeout) throws MQClientException, RemotingException, MQBrokerException, InterruptedException;
>
>
>
> Message request(final Message msg, final SendCallback sendCallback, final long timeout) throws MQClientException, RemotingException, InterruptedException;
>
>
>
> Message request(final Message msg, final MessageQueueSelector selector, final Object arg, final long timeout) throws MQClientException, RemotingException, MQBrokerException, InterruptedException;
>
>
>
> Message request(final Message msg, final MessageQueueSelector selector, final Object arg, final SendCallback sendCallback, final long timeout) throws MQClientException, RemotingException, InterruptedException;
>
>
>
> Message request(final Message msg, final MessageQueue MQ, final long timeout) throws MQClientException, RemotingException, MQBrokerException, InterruptedException;
>
>
>
> Message request(final Message msg, final MessageQueue mq, final SendCallback sendCallback, long timeout) throws MQClientException, RemotingException, InterruptedException;
>
>
>
> Method behavior changes
> No issue
>
> CLI command changes
> No issue
>
> Log format or content changes
> No issue
>
> Compatibility, Deprecation, and Migration Plan
>
> No issue
> Implementation Outline
>
> We will implement the proposed changes by 1 phase.
>
> Phase 1
>
> Implement RPC feature in Producer
> Implement RPC feature in Consumer
> Implement RPC feature in Broker
Re: [VOTE][RIP-16]RocketMQ RPC(Request-Response model) Support
Posted by Gosling Von <fe...@gmail.com>.
+1
Glad to see the strong desire for microservice/servicemesh in community. Let it be native in RocketMQ :-)
Best Regards,
Von Gosling
> On Sep 6, 2019, at 11:35 AM, heng du <du...@gmail.com> wrote:
>
> Hello RocketMQ Community,
>
> This is the vote for the kickoff of RIP-16 RocketMQ Request-Response model support
>
> RPC is a powerful technique for constructing distributed, client-server based applications. Many companies use the MQ system to constructing their service bus, especially in the financial industry. We need to implement an RPC client based on MQ system ourselves because the MQ system doesn’t support RPC naturally. In the current version of rocketmq project, producer client only support to send a message to the broker and cannot wait a response message replied from the consumer. We wish RocketMQ can provide an RPC client implement to help developers building their applications conveniently and effectively.
>
>
> The vote will be open for at least 72 hours or until a necessary number of votes are reached.
>
> Please vote accordingly:
>
> [ ] +1 approve
> [ ] +0 no opinion
> [ ] -1 disapprove with the reason
>
>
> Thanks,
> The Apache RocketMQ Team
>
> heng du <duhengforever@gmail.com <ma...@gmail.com>> 于2019年9月6日周五 上午11:32写道：
> @wenfeng
>
> Actually, Building RPC based on message queue is a very traditional approach, especially in the previous ESB, SOA era. Of course, in today's micro-services, there are many benefits to building micro-services based on MQ.
>
> For example, at the transport layer level, MQ can provide true asynchronous communication for RPC. In terms of visualization, MQ can also provide better visibility and make it easier to replay traffic to locate or fix issues, which is very important in event-driven architectures. Most important of all, direct RPC will make the access relationship between services become mesh, but based on MQ, the problem of network mesh calls are solved. In many industries, such as the financial industry, it is difficult to provide all the network access.
> Moreover, the request-response model can be used to make RocketMQ integrate well into various infrastructures. In addition, many of the same types of message middleware also provide request-response access methods.
>
> So I think that supporting the request-response model will increase the competitiveness of RocketMQ and better expand the usage scenario.
>
>
> wenfeng wang <sxian.wang@gmail.com <ma...@gmail.com>> 于2019年8月27日周二 下午6:15写道：
> IMO, The most popular scenario of MQ System is that decouple complex distributed system and process message asynchronous. If a user wants low latency or explicit response from downstream, he should use an RPC Framework instead of MQ, like Dubbo, gRPC, etc. so I vote for -1.
>
>
> heng du <duhengforever@gmail.com <ma...@gmail.com>> 于2019年8月27日周二 下午5:54写道：
> Dear Apache RocketMQ Community:
>
> We would like to propose a RIP[16] about RocketMQ RPC(Request-Response model) Support. Many companies use the MQ system to constructing their service bus, especially in the financial industry. We wish RocketMQ can provide an RPC client implement to help developers building their applications conveniently and effectively.
>
> Status
> Current State: Proposed
>
> Authors: qqeasonchen
>
> Shepherds: duhengforever
>
> Mailing List discussion: dev, users
>
> Pull Request: none
>
> Released: 4.6.0
>
> Background & Motivation
>
> RPC is a powerful technique for constructing distributed, client-server based applications. Many companies use the MQ system to constructing their service bus, especially in the financial industry. We need to implement an RPC client based on MQ system ourselves because the MQ system doesn’t support RPC naturally. In the current version of rocketmq project, producer client only support to send a message to the broker and cannot wait a response message replied from the consumer. We wish RocketMQ can provide an RPC client implement to help developers building their applications conveniently and effectively.
>
> Goals
>
> What problem is this proposal designed to solve?
> (1) Design and implement an RPC interface based on RocketMQ Producer, which support send a message and then wait a response message replied from the consumer.
>
> (2) Design and Implement a consumer which can automatically or manually send a reply message.
>
> (3) Enable the broker to push a message to an explicit producer.
>
>
>
> To what degree should we solve the problem?
> We wish developers can use RocketMQ easily to constructing their distributed applications which need RPC call.
>
> Non-Goals
>
> What problem is this proposal NOT designed to solve?
> In this phase, this rip only supports a usable RPC call in most common scenarios.
>
> Are there any limits to this proposal?
> Users may need to tune some client and broker’s configurations to achieve better performance.
>
> Changes
>
> Architecture
>
> We plan to add RPC implement into client and broker modules. In client modules, we will add an RPC interface into DefaultMQProducer, and add reply logic into DefaultMQPushConsumer. In broker modules, we will add a processor to push reply message from consumer to explicit producer.
>
> Interface Design/Change
>
> Method signature changes
> Plan to add interfaces as follow:
>
> Message request(final Message msg, final long timeout) throws MQClientException, RemotingException, MQBrokerException, InterruptedException;
>
>
>
> Message request(final Message msg, final SendCallback sendCallback, final long timeout) throws MQClientException, RemotingException, InterruptedException;
>
>
>
> Message request(final Message msg, final MessageQueueSelector selector, final Object arg, final long timeout) throws MQClientException, RemotingException, MQBrokerException, InterruptedException;
>
>
>
> Message request(final Message msg, final MessageQueueSelector selector, final Object arg, final SendCallback sendCallback, final long timeout) throws MQClientException, RemotingException, InterruptedException;
>
>
>
> Message request(final Message msg, final MessageQueue MQ, final long timeout) throws MQClientException, RemotingException, MQBrokerException, InterruptedException;
>
>
>
> Message request(final Message msg, final MessageQueue mq, final SendCallback sendCallback, long timeout) throws MQClientException, RemotingException, InterruptedException;
>
>
>
> Method behavior changes
> No issue
>
> CLI command changes
> No issue
>
> Log format or content changes
> No issue
>
> Compatibility, Deprecation, and Migration Plan
>
> No issue
> Implementation Outline
>
> We will implement the proposed changes by 1 phase.
>
> Phase 1
>
> Implement RPC feature in Producer
> Implement RPC feature in Consumer
> Implement RPC feature in Broker
Re: [VOTE][RIP-16]RocketMQ RPC(Request-Response model) Support
Posted by wenfeng wang <sx...@gmail.com>.
+1
Thanks for your sincere explanation @duheng!
superheizai <su...@aliyun.com> 于2019年9月6日周五 下午1:49写道：
> +1
> Service Bus model is very popular in enterprise.
>
> ------------------------------------------------------------------
> 发件人：heng du <du...@gmail.com>
> 发送时间：2019年9月6日(星期五) 11:36
> 收件人：dev <de...@rocketmq.apache.org>
> 抄 送：users <us...@rocketmq.apache.org>
> 主 题：[VOTE][RIP-16]RocketMQ RPC(Request-Response model) Support
>
> Hello RocketMQ Community,
>
> This is the vote for the kickoff of RIP-16 RocketMQ Request-Response
> model support
>
> RPC is a powerful technique for constructing distributed, client-server
> based applications. Many companies use the MQ system to constructing their
> service bus, especially in the financial industry. We need to implement an
> RPC client based on MQ system ourselves because the MQ system doesn’t
> support RPC naturally. In the current version of rocketmq project, producer
> client only support to send a message to the broker and cannot wait a
> response message replied from the consumer. We wish RocketMQ can provide an
> RPC client implement to help developers building their applications
> conveniently and effectively.
>
>
> The vote will be open for at least 72 hours or until a necessary number of
> votes are reached.
>
> Please vote accordingly:
>
> [ ] +1 approve
> [ ] +0 no opinion
> [ ] -1 disapprove with the reason
>
>
> Thanks,
> The Apache RocketMQ Team
>
> heng du <du...@gmail.com> 于2019年9月6日周五 上午11:32写道：
> @wenfeng
>
> Actually, Building RPC based on message queue is a very traditional
> approach, especially in the previous ESB, SOA era. Of course, in today's
> micro-services, there are many benefits to building micro-services based on
> MQ.
>
> For example, at the transport layer level, MQ can provide true
> asynchronous communication for RPC. In terms of visualization, MQ can also
> provide better visibility and make it easier to replay traffic to locate or
> fix issues, which is very important in event-driven architectures. Most
> important of all, direct RPC will make the access relationship between
> services become mesh, but based on MQ, the problem of network mesh calls
> are solved. In many industries, such as the financial industry, it is
> difficult to provide all the network access.
> Moreover, the request-response model can be used to make RocketMQ
> integrate well into various infrastructures. In addition, many of the same
> types of message middleware also provide request-response access methods.
>
> So I think that supporting the request-response model will increase the
> competitiveness of RocketMQ and better expand the usage scenario.
>
>
> wenfeng wang <sx...@gmail.com> 于2019年8月27日周二 下午6:15写道：
> IMO, The most popular scenario of MQ System is that decouple complex
> distributed system and process message asynchronous. If a user wants low
> latency or explicit response from downstream, he should use an RPC
> Framework instead of MQ, like Dubbo, gRPC, etc. so I vote for -1.
>
>
> heng du <du...@gmail.com> 于2019年8月27日周二 下午5:54写道：
>
> Dear Apache RocketMQ Community:
>
> We would like to propose a RIP[16] about RocketMQ RPC(Request-Response
> model) Support. Many companies use the MQ system to constructing their
> service bus, especially in the financial industry. We wish RocketMQ can
> provide an RPC client implement to help developers building their
> applications conveniently and effectively.
>
>
> Status
>
> Current State: Proposed
>
> Authors: qqeasonchen
>
> Shepherds: duhengforever
>
> Mailing List discussion: dev, users
>
> Pull Request: none
>
> Released: 4.6.0
>
> Background & Motivation
>
> RPC is a powerful technique for constructing distributed, client-server
> based applications. Many companies use the MQ system to constructing their
> service bus, especially in the financial industry. We need to implement an
> RPC client based on MQ system ourselves because the MQ system doesn’t
> support RPC naturally. In the current version of rocketmq project, producer
> client only support to send a message to the broker and cannot wait a
> response message replied from the consumer. We wish RocketMQ can provide an
> RPC client implement to help developers building their applications
> conveniently and effectively.
>
> Goals
>
> - What problem is this proposal designed to solve?
>
> (1) Design and implement an RPC interface based on RocketMQ Producer,
> which support send a message and then wait a response message replied from
> the consumer.
>
> (2) Design and Implement a consumer which can automatically or manually
> send a reply message.
>
> (3) Enable the broker to push a message to an explicit producer.
>
>
>
> - To what degree should we solve the problem?
>
> We wish developers can use RocketMQ easily to constructing their
> distributed applications which need RPC call.
>
> Non-Goals
>
> - What problem is this proposal NOT designed to solve?
>
> In this phase, this rip only supports a usable RPC call in most common
> scenarios.
>
> - Are there any limits to this proposal?
>
> Users may need to tune some client and broker’s configurations to achieve
> better performance.
>
> Changes
>
> Architecture
>
> We plan to add RPC implement into client and broker modules. In client
> modules, we will add an RPC interface into DefaultMQProducer, and add reply
> logic into DefaultMQPushConsumer. In broker modules, we will add a
> processor to push reply message from consumer to explicit producer.
>
> Interface Design/Change
>
> - Method signature changes
>
> Plan to add interfaces as follow:
>
>
> Message request(final Message msg, final long timeout) throws MQClientException, RemotingException, MQBrokerException, InterruptedException;
>
>
>
> Message request(final Message msg, final SendCallback sendCallback, final
> long timeout) throws MQClientException, RemotingException,
> InterruptedException;
>
>
>
> Message request(final Message msg, final MessageQueueSelector selector,
> final Object arg, final long timeout) throws MQClientException,
> RemotingException, MQBrokerException, InterruptedException;
>
>
>
> Message request(final Message msg, final MessageQueueSelector selector,
> final Object arg, final SendCallback sendCallback, final long timeout)
> throws MQClientException, RemotingException, InterruptedException;
>
>
>
> Message request(final Message msg, final MessageQueue MQ, final long
> timeout) throws MQClientException, RemotingException, MQBrokerException,
> InterruptedException;
>
>
>
> Message request(final Message msg, final MessageQueue mq, final
> SendCallback sendCallback, long timeout) throws MQClientException,
> RemotingException, InterruptedException;
>
>
>
> - Method behavior changes
>
> No issue
>
> - CLI command changes
>
> No issue
>
> - Log format or content changes
>
> No issue
>
> Compatibility, Deprecation, and Migration Plan
>
> - No issue
>
> Implementation Outline
>
> We will implement the proposed changes by *1* phase.
>
> Phase 1
>
> 1. Implement RPC feature in Producer
> 2. Implement RPC feature in Consumer
> 3. Implement RPC feature in Broker
>
>
回复：[VOTE][RIP-16]RocketMQ RPC(Request-Response model) Support
Posted by superheizai <su...@aliyun.com.INVALID>.
+1
Service Bus model is very popular in enterprise.
------------------------------------------------------------------
发件人：heng du <du...@gmail.com>
发送时间：2019年9月6日(星期五) 11:36
收件人：dev <de...@rocketmq.apache.org>
抄 送：users <us...@rocketmq.apache.org>
主 题：[VOTE][RIP-16]RocketMQ RPC(Request-Response model) Support
Hello RocketMQ Community,
This is the vote for the kickoff of RIP-16 RocketMQ Request-Response model support
RPC is a powerful technique for constructing distributed, client-server based applications. Many companies use the MQ system to constructing their service bus, especially in the financial industry. We need to implement an RPC client based on MQ system ourselves because the MQ system doesn’t support RPC naturally. In the current version of rocketmq project, producer client only support to send a message to the broker and cannot wait a response message replied from the consumer. We wish RocketMQ can provide an RPC client implement to help developers building their applications conveniently and effectively.
The vote will be open for at least 72 hours or until a necessary number of votes are reached.
Please vote accordingly:
[ ] +1 approve
[ ] +0 no opinion
[ ] -1 disapprove with the reason
Thanks,
The Apache RocketMQ Team
heng du <du...@gmail.com> 于2019年9月6日周五 上午11:32写道：
@wenfeng
Actually, Building RPC based on message queue is a very traditional approach, especially in the previous ESB, SOA era. Of course, in today's micro-services, there are many benefits to building micro-services based on MQ.
For example, at the transport layer level, MQ can provide true asynchronous communication for RPC. In terms of visualization, MQ can also provide better visibility and make it easier to replay traffic to locate or fix issues, which is very important in event-driven architectures. Most important of all, direct RPC will make the access relationship between services become mesh, but based on MQ, the problem of network mesh calls are solved. In many industries, such as the financial industry, it is difficult to provide all the network access.
Moreover, the request-response model can be used to make RocketMQ integrate well into various infrastructures. In addition, many of the same types of message middleware also provide request-response access methods.
So I think that supporting the request-response model will increase the competitiveness of RocketMQ and better expand the usage scenario.
wenfeng wang <sx...@gmail.com> 于2019年8月27日周二 下午6:15写道：
IMO, The most popular scenario of MQ System is that decouple complex distributed system and process message asynchronous. If a user wants low latency or explicit response from downstream, he should use an RPC Framework instead of MQ, like Dubbo, gRPC, etc. so I vote for -1.
heng du <du...@gmail.com> 于2019年8月27日周二 下午5:54写道：
Dear Apache RocketMQ Community:
We would like to propose a RIP[16] about RocketMQ RPC(Request-Response model) Support. Many companies use the MQ system to constructing their service bus, especially in the financial industry. We wish RocketMQ can provide an RPC client implement to help developers building their applications conveniently and effectively.
Status
Current State: Proposed
Authors: qqeasonchen
Shepherds: duhengforever
Mailing List discussion: dev, users
Pull Request: none
Released: 4.6.0
Background & Motivation
RPC is a powerful technique for constructing distributed, client-server based applications. Many companies use the MQ system to constructing their service bus, especially in the financial industry. We need to implement an RPC client based on MQ system ourselves because the MQ system doesn’t support RPC naturally. In the current version of rocketmq project, producer client only support to send a message to the broker and cannot wait a response message replied from the consumer. We wish RocketMQ can provide an RPC client implement to help developers building their applications conveniently and effectively.
Goals
What problem is this proposal designed to solve?
(1) Design and implement an RPC interface based on RocketMQ Producer, which support send a message and then wait a response message replied from the consumer.
(2) Design and Implement a consumer which can automatically or manually send a reply message.
(3) Enable the broker to push a message to an explicit producer.
To what degree should we solve the problem?
We wish developers can use RocketMQ easily to constructing their distributed applications which need RPC call.
Non-Goals
What problem is this proposal NOT designed to solve?
In this phase, this rip only supports a usable RPC call in most common scenarios.
Are there any limits to this proposal?
Users may need to tune some client and broker’s configurations to achieve better performance.
Changes
Architecture
We plan to add RPC implement into client and broker modules. In client modules, we will add an RPC interface into DefaultMQProducer, and add reply logic into DefaultMQPushConsumer. In broker modules, we will add a processor to push reply message from consumer to explicit producer.
Interface Design/Change
Method signature changes
Plan to add interfaces as follow:
Message request(final Message msg, final long timeout) throws MQClientException, RemotingException, MQBrokerException, InterruptedException;
Message request(final Message msg, final SendCallback sendCallback, final long timeout) throws MQClientException, RemotingException, InterruptedException;
Message request(final Message msg, final MessageQueueSelector selector, final Object arg, final long timeout) throws MQClientException, RemotingException, MQBrokerException, InterruptedException;
Message request(final Message msg, final MessageQueueSelector selector, final Object arg, final SendCallback sendCallback, final long timeout) throws MQClientException, RemotingException, InterruptedException;
Message request(final Message msg, final MessageQueue MQ, final long timeout) throws MQClientException, RemotingException, MQBrokerException, InterruptedException;
Message request(final Message msg, final MessageQueue mq, final SendCallback sendCallback, long timeout) throws MQClientException, RemotingException, InterruptedException;
Method behavior changes
No issue
CLI command changes
No issue
Log format or content changes
No issue
Compatibility, Deprecation, and Migration Plan
No issue
Implementation Outline
We will implement the proposed changes by 1 phase.
Phase 1
Implement RPC feature in Producer
Implement RPC feature in Consumer
Implement RPC feature in Broker
回复：[VOTE][RIP-16]RocketMQ RPC(Request-Response model) Support
Posted by superheizai <su...@aliyun.com>.
+1
Service Bus model is very popular in enterprise.
------------------------------------------------------------------
发件人：heng du <du...@gmail.com>
发送时间：2019年9月6日(星期五) 11:36
收件人：dev <de...@rocketmq.apache.org>
抄 送：users <us...@rocketmq.apache.org>
主 题：[VOTE][RIP-16]RocketMQ RPC(Request-Response model) Support
Hello RocketMQ Community,
This is the vote for the kickoff of RIP-16 RocketMQ Request-Response model support
RPC is a powerful technique for constructing distributed, client-server based applications. Many companies use the MQ system to constructing their service bus, especially in the financial industry. We need to implement an RPC client based on MQ system ourselves because the MQ system doesn’t support RPC naturally. In the current version of rocketmq project, producer client only support to send a message to the broker and cannot wait a response message replied from the consumer. We wish RocketMQ can provide an RPC client implement to help developers building their applications conveniently and effectively.
The vote will be open for at least 72 hours or until a necessary number of votes are reached.
Please vote accordingly:
[ ] +1 approve
[ ] +0 no opinion
[ ] -1 disapprove with the reason
Thanks,
The Apache RocketMQ Team
heng du <du...@gmail.com> 于2019年9月6日周五 上午11:32写道：
@wenfeng
Actually, Building RPC based on message queue is a very traditional approach, especially in the previous ESB, SOA era. Of course, in today's micro-services, there are many benefits to building micro-services based on MQ.
For example, at the transport layer level, MQ can provide true asynchronous communication for RPC. In terms of visualization, MQ can also provide better visibility and make it easier to replay traffic to locate or fix issues, which is very important in event-driven architectures. Most important of all, direct RPC will make the access relationship between services become mesh, but based on MQ, the problem of network mesh calls are solved. In many industries, such as the financial industry, it is difficult to provide all the network access.
Moreover, the request-response model can be used to make RocketMQ integrate well into various infrastructures. In addition, many of the same types of message middleware also provide request-response access methods.
So I think that supporting the request-response model will increase the competitiveness of RocketMQ and better expand the usage scenario.
wenfeng wang <sx...@gmail.com> 于2019年8月27日周二 下午6:15写道：
IMO, The most popular scenario of MQ System is that decouple complex distributed system and process message asynchronous. If a user wants low latency or explicit response from downstream, he should use an RPC Framework instead of MQ, like Dubbo, gRPC, etc. so I vote for -1.
heng du <du...@gmail.com> 于2019年8月27日周二 下午5:54写道：
Dear Apache RocketMQ Community:
We would like to propose a RIP[16] about RocketMQ RPC(Request-Response model) Support. Many companies use the MQ system to constructing their service bus, especially in the financial industry. We wish RocketMQ can provide an RPC client implement to help developers building their applications conveniently and effectively.
Status
Current State: Proposed
Authors: qqeasonchen
Shepherds: duhengforever
Mailing List discussion: dev, users
Pull Request: none
Released: 4.6.0
Background & Motivation
RPC is a powerful technique for constructing distributed, client-server based applications. Many companies use the MQ system to constructing their service bus, especially in the financial industry. We need to implement an RPC client based on MQ system ourselves because the MQ system doesn’t support RPC naturally. In the current version of rocketmq project, producer client only support to send a message to the broker and cannot wait a response message replied from the consumer. We wish RocketMQ can provide an RPC client implement to help developers building their applications conveniently and effectively.
Goals
What problem is this proposal designed to solve?
(1) Design and implement an RPC interface based on RocketMQ Producer, which support send a message and then wait a response message replied from the consumer.
(2) Design and Implement a consumer which can automatically or manually send a reply message.
(3) Enable the broker to push a message to an explicit producer.
To what degree should we solve the problem?
We wish developers can use RocketMQ easily to constructing their distributed applications which need RPC call.
Non-Goals
What problem is this proposal NOT designed to solve?
In this phase, this rip only supports a usable RPC call in most common scenarios.
Are there any limits to this proposal?
Users may need to tune some client and broker’s configurations to achieve better performance.
Changes
Architecture
We plan to add RPC implement into client and broker modules. In client modules, we will add an RPC interface into DefaultMQProducer, and add reply logic into DefaultMQPushConsumer. In broker modules, we will add a processor to push reply message from consumer to explicit producer.
Interface Design/Change
Method signature changes
Plan to add interfaces as follow:
Message request(final Message msg, final long timeout) throws MQClientException, RemotingException, MQBrokerException, InterruptedException;
Message request(final Message msg, final SendCallback sendCallback, final long timeout) throws MQClientException, RemotingException, InterruptedException;
Message request(final Message msg, final MessageQueueSelector selector, final Object arg, final long timeout) throws MQClientException, RemotingException, MQBrokerException, InterruptedException;
Message request(final Message msg, final MessageQueueSelector selector, final Object arg, final SendCallback sendCallback, final long timeout) throws MQClientException, RemotingException, InterruptedException;
Message request(final Message msg, final MessageQueue MQ, final long timeout) throws MQClientException, RemotingException, MQBrokerException, InterruptedException;
Message request(final Message msg, final MessageQueue mq, final SendCallback sendCallback, long timeout) throws MQClientException, RemotingException, InterruptedException;
Method behavior changes
No issue
CLI command changes
No issue
Log format or content changes
No issue
Compatibility, Deprecation, and Migration Plan
No issue
Implementation Outline
We will implement the proposed changes by 1 phase.
Phase 1
Implement RPC feature in Producer
Implement RPC feature in Consumer
Implement RPC feature in Broker
Re: [VOTE][RIP-16]RocketMQ RPC(Request-Response model) Support
Posted by liqipeng <wl...@163.com>.
+1
> 在 2019年9月6日，上午11:35，heng du <du...@gmail.com> 写道：
>
> Hello RocketMQ Community,
>
> This is the vote for the kickoff of RIP-16 RocketMQ Request-Response model
> support
>
> RPC is a powerful technique for constructing distributed, client-server
> based applications. Many companies use the MQ system to constructing their
> service bus, especially in the financial industry. We need to implement an
> RPC client based on MQ system ourselves because the MQ system doesn’t
> support RPC naturally. In the current version of rocketmq project, producer
> client only support to send a message to the broker and cannot wait a
> response message replied from the consumer. We wish RocketMQ can provide an
> RPC client implement to help developers building their applications
> conveniently and effectively.
>
>
> The vote will be open for at least 72 hours or until a necessary number of
> votes are reached.
>
> Please vote accordingly:
>
> [ ] +1 approve
> [ ] +0 no opinion
> [ ] -1 disapprove with the reason
>
>
> Thanks,
> The Apache RocketMQ Team
>
> heng du <du...@gmail.com> 于2019年9月6日周五 上午11:32写道：
>
>> @wenfeng
>>
>> Actually, Building RPC based on message queue is a very traditional
>> approach, especially in the previous ESB, SOA era. Of course, in today's
>> micro-services, there are many benefits to building micro-services based on
>> MQ.
>>
>> For example, at the transport layer level, MQ can provide true
>> asynchronous communication for RPC. In terms of visualization, MQ can also
>> provide better visibility and make it easier to replay traffic to locate or
>> fix issues, which is very important in event-driven architectures. Most
>> important of all, direct RPC will make the access relationship between
>> services become mesh, but based on MQ, the problem of network mesh calls
>> are solved. In many industries, such as the financial industry, it is
>> difficult to provide all the network access.
>> Moreover, the request-response model can be used to make RocketMQ
>> integrate well into various infrastructures. In addition, many of the same
>> types of message middleware also provide request-response access methods.
>>
>> So I think that supporting the request-response model will increase the
>> competitiveness of RocketMQ and better expand the usage scenario.
>>
>>
>> wenfeng wang <sx...@gmail.com> 于2019年8月27日周二 下午6:15写道：
>>
>>> IMO, The most popular scenario of MQ System is that decouple complex
>>> distributed system and process message asynchronous. If a user wants low
>>> latency or explicit response from downstream, he should use an RPC
>>> Framework instead of MQ, like Dubbo, gRPC, etc. so I vote for -1.
>>>
>>>
>>> heng du <du...@gmail.com> 于2019年8月27日周二 下午5:54写道：
>>>
>>>> Dear Apache RocketMQ Community:
>>>>
>>>> We would like to propose a RIP[16] about RocketMQ RPC(Request-Response
>>>> model) Support. Many companies use the MQ system to constructing their
>>>> service bus, especially in the financial industry. We wish RocketMQ can
>>>> provide an RPC client implement to help developers building their
>>>> applications conveniently and effectively.
>>>>
>>>>
>>>> Status
>>>>
>>>> Current State: Proposed
>>>>
>>>> Authors: qqeasonchen
>>>>
>>>> Shepherds: duhengforever
>>>>
>>>> Mailing List discussion: dev, users
>>>>
>>>> Pull Request: none
>>>>
>>>> Released: 4.6.0
>>>>
>>>> Background & Motivation
>>>>
>>>> RPC is a powerful technique for constructing distributed, client-server
>>>> based applications. Many companies use the MQ system to constructing their
>>>> service bus, especially in the financial industry. We need to implement an
>>>> RPC client based on MQ system ourselves because the MQ system doesn’t
>>>> support RPC naturally. In the current version of rocketmq project, producer
>>>> client only support to send a message to the broker and cannot wait a
>>>> response message replied from the consumer. We wish RocketMQ can provide an
>>>> RPC client implement to help developers building their applications
>>>> conveniently and effectively.
>>>>
>>>> Goals
>>>>
>>>> - What problem is this proposal designed to solve?
>>>>
>>>> (1) Design and implement an RPC interface based on RocketMQ Producer,
>>>> which support send a message and then wait a response message replied from
>>>> the consumer.
>>>>
>>>> (2) Design and Implement a consumer which can automatically or manually
>>>> send a reply message.
>>>>
>>>> (3) Enable the broker to push a message to an explicit producer.
>>>>
>>>>
>>>>
>>>> - To what degree should we solve the problem?
>>>>
>>>> We wish developers can use RocketMQ easily to constructing their
>>>> distributed applications which need RPC call.
>>>>
>>>> Non-Goals
>>>>
>>>> - What problem is this proposal NOT designed to solve?
>>>>
>>>> In this phase, this rip only supports a usable RPC call in most common
>>>> scenarios.
>>>>
>>>> - Are there any limits to this proposal?
>>>>
>>>> Users may need to tune some client and broker’s configurations to
>>>> achieve better performance.
>>>>
>>>> Changes
>>>>
>>>> Architecture
>>>>
>>>> We plan to add RPC implement into client and broker modules. In client
>>>> modules, we will add an RPC interface into DefaultMQProducer, and add reply
>>>> logic into DefaultMQPushConsumer. In broker modules, we will add a
>>>> processor to push reply message from consumer to explicit producer.
>>>>
>>>> Interface Design/Change
>>>>
>>>> - Method signature changes
>>>>
>>>> Plan to add interfaces as follow:
>>>>
>>>>
>>>> Message request(final Message msg, final long timeout) throws MQClientException, RemotingException, MQBrokerException, InterruptedException;
>>>>
>>>>
>>>>
>>>> Message request(final Message msg, final SendCallback sendCallback,
>>>> final long timeout) throws MQClientException, RemotingException,
>>>> InterruptedException;
>>>>
>>>>
>>>>
>>>> Message request(final Message msg, final MessageQueueSelector selector,
>>>> final Object arg, final long timeout) throws MQClientException,
>>>> RemotingException, MQBrokerException, InterruptedException;
>>>>
>>>>
>>>>
>>>> Message request(final Message msg, final MessageQueueSelector selector,
>>>> final Object arg, final SendCallback sendCallback, final long timeout)
>>>> throws MQClientException, RemotingException, InterruptedException;
>>>>
>>>>
>>>>
>>>> Message request(final Message msg, final MessageQueue MQ, final long
>>>> timeout) throws MQClientException, RemotingException, MQBrokerException,
>>>> InterruptedException;
>>>>
>>>>
>>>>
>>>> Message request(final Message msg, final MessageQueue mq, final
>>>> SendCallback sendCallback, long timeout) throws MQClientException,
>>>> RemotingException, InterruptedException;
>>>>
>>>>
>>>>
>>>> - Method behavior changes
>>>>
>>>> No issue
>>>>
>>>> - CLI command changes
>>>>
>>>> No issue
>>>>
>>>> - Log format or content changes
>>>>
>>>> No issue
>>>>
>>>> Compatibility, Deprecation, and Migration Plan
>>>>
>>>> - No issue
>>>>
>>>> Implementation Outline
>>>>
>>>> We will implement the proposed changes by *1* phase.
>>>>
>>>> Phase 1
>>>>
>>>> 1. Implement RPC feature in Producer
>>>> 2. Implement RPC feature in Consumer
>>>> 3. Implement RPC feature in Broker
>>>>
>>>>
Re:[VOTE][RIP-16]RocketMQ RPC(Request-Response model) Support
Posted by ShannonDing <di...@apache.org>.
+1
On 09/6/2019 11:35，heng du<du...@gmail.com> wrote：
Hello RocketMQ Community,
This is the vote for the kickoff of RIP-16 RocketMQ Request-Response model support
RPC is a powerful technique for constructing distributed, client-server based applications. Many companies use the MQ system to constructing their service bus, especially in the financial industry. We need to implement an RPC client based on MQ system ourselves because the MQ system doesn’t support RPC naturally. In the current version of rocketmq project, producer client only support to send a message to the broker and cannot wait a response message replied from the consumer. We wish RocketMQ can provide an RPC client implement to help developers building their applications conveniently and effectively.
The vote will be open for at least 72 hours or until a necessary number of votes are reached.
Please vote accordingly:
[ ] +1 approve
[ ] +0 no opinion
[ ] -1 disapprove with the reason
Thanks,
The Apache RocketMQ Team
heng du <du...@gmail.com> 于2019年9月6日周五 上午11:32写道：
@wenfeng
Actually, Building RPC based on message queue is a very traditional approach, especially in the previous ESB, SOA era. Of course, in today's micro-services, there are many benefits to building micro-services based on MQ.
For example, at the transport layer level, MQ can provide true asynchronous communication for RPC. In terms of visualization, MQ can also provide better visibility and make it easier to replay traffic to locate or fix issues, which is very important in event-driven architectures. Most important of all, direct RPC will make the access relationship between services become mesh, but based on MQ, the problem of network mesh calls are solved. In many industries, such as the financial industry, it is difficult to provide all the network access.
Moreover, the request-response model can be used to make RocketMQ integrate well into various infrastructures. In addition, many of the same types of message middleware also provide request-response access methods.
So I think that supporting the request-response model will increase the competitiveness of RocketMQ and better expand the usage scenario.
wenfeng wang <sx...@gmail.com> 于2019年8月27日周二 下午6:15写道：
IMO, The most popular scenario of MQ System is that decouple complex distributed system and process message asynchronous. If a user wants low latency or explicit response from downstream, he should use an RPC Framework instead of MQ, like Dubbo, gRPC, etc. so I vote for -1.
heng du <du...@gmail.com> 于2019年8月27日周二 下午5:54写道：
Dear Apache RocketMQ Community:
We would like to propose a RIP[16] about RocketMQ RPC(Request-Response model) Support. Many companies use the MQ system to constructing their service bus, especially in the financial industry. We wish RocketMQ can provide an RPC client implement to help developers building their applications conveniently and effectively.
Status
Current State: Proposed
Authors: qqeasonchen
Shepherds: duhengforever
Mailing List discussion: dev, users
Pull Request: none
Released: 4.6.0
Background & Motivation
RPC is a powerful technique for constructing distributed, client-server based applications. Many companies use the MQ system to constructing their service bus, especially in the financial industry. We need to implement an RPC client based on MQ system ourselves because the MQ system doesn’t support RPC naturally. In the current version of rocketmq project, producer client only support to send a message to the broker and cannot wait a response message replied from the consumer. We wish RocketMQ can provide an RPC client implement to help developers building their applications conveniently and effectively.
Goals
What problem is this proposal designed to solve?
(1) Design and implement an RPC interface based on RocketMQ Producer, which support send a message and then wait a response message replied from the consumer.
(2) Design and Implement a consumer which can automatically or manually send a reply message.
(3) Enable the broker to push a message to an explicit producer.
To what degree should we solve the problem?
We wish developers can use RocketMQ easily to constructing their distributed applications which need RPC call.
Non-Goals
What problem is this proposal NOT designed to solve?
In this phase, this rip only supports a usable RPC call in most common scenarios.
Are there any limits to this proposal?
Users may need to tune some client and broker’s configurations to achieve better performance.
Changes
Architecture
We plan to add RPC implement into client and broker modules. In client modules, we will add an RPC interface into DefaultMQProducer, and add reply logic into DefaultMQPushConsumer. In broker modules, we will add a processor to push reply message from consumer to explicit producer.
Interface Design/Change
Method signature changes
Plan to add interfaces as follow:
Message request(final Message msg, final long timeout) throws MQClientException, RemotingException, MQBrokerException, InterruptedException;
Message request(final Message msg, final SendCallback sendCallback, final long timeout) throws MQClientException, RemotingException, InterruptedException;
Message request(final Message msg, final MessageQueueSelector selector, final Object arg, final long timeout) throws MQClientException, RemotingException, MQBrokerException, InterruptedException;
Message request(final Message msg, final MessageQueueSelector selector, final Object arg, final SendCallback sendCallback, final long timeout) throws MQClientException, RemotingException, InterruptedException;
Message request(final Message msg, final MessageQueue MQ, final long timeout) throws MQClientException, RemotingException, MQBrokerException, InterruptedException;
Message request(final Message msg, final MessageQueue mq, final SendCallback sendCallback, long timeout) throws MQClientException, RemotingException, InterruptedException;
Method behavior changes
No issue
CLI command changes
No issue
Log format or content changes
No issue
Compatibility, Deprecation, and Migration Plan
No issue
Implementation Outline
We will implement the proposed changes by 1 phase.
Phase 1
Implement RPC feature in Producer
Implement RPC feature in Consumer
Implement RPC feature in Broker