The focus is not on RPC, but on the Request-Reply synchronous call model. This is a relatively simple function enhancement.
As mentioned in the second article above. For the same topic, each message can be sent synchronously or asynchronously. That is to say, the request can be initiated synchronously or asynchronously, and the server (consumer) returns the result after processing. The motivation part of the proposal is also explained. There are some applications related to this request-reply call model. Related to spring: https://github.com/apache/rocketmq-spring/wiki/Request-reply-message-exchange-pattern I don't know much about pulsar-spring. I think my proposal can also enhance the use of pulsar-spring. It's not the kind of implementation that uses request topic and reply topic. Thanks, sinan Aurora Twinkle <foreverlove...@gmail.com>于2024年8月9日 周五10:41写道： > Thanks for the meaningful proposal! > > But I am very curious about your motivation for proposing this PIP. If > RPC is needed, why not use a professional RPC framework such as gRPC > or bRPC? In my opinion, pulsar is already bloated enough, and we > should be cautious about adding such features that may not be used. I > believe that most companies will choose to use gRPC or bRPC. There is > no reason to choose pulsar as an RPC framework. The pulsar core > library should do its job well, that is, the message queue, instead of > trying to get involved in everything, which will eventually become > irreversible. > > Finally, perhaps we should collect user needs and confirm whether > there are really many companies that need to use pulsar for RPC. > Otherwise, we should not carry out this work. > > BR, > aurora > > SiNan Liu <liusinan1...@gmail.com> 于2024年8月9日周五 09:10写道： > > > > Thank you for your comments. > > > > I took a look at this. There are a few questions. > > > > 1. Compared with my proposal to directly add new functions in > > pulsar-client, the implementation in this repo is through two topics, one > > request topic and one reply topic. The producer sends the message to the > > request topic, the consumer processes it, the consumer sends it to the > > reply topic, and the producer subscribes to the reply topic. Such a call > > would have a long link and lose performance. This is also the downside of > > the external repo wrapping the pulsar-client api directly, which it can > > only do. > > > > And that's not in my proposal. After the consumer processes the request > > Message, it passes it to the broker through a new ack implementation, and > > the broker passes the reply result directly to the client (producer). > > > > > > 2. In my proposal, request and the existing send function of pulsar can > be > > mixed. This means that the user can choose, and the call to the server > side > > (consumer) can be asynchronous or synchronous, which is controlled by the > > user flexibly. > > > > > > 3. The use examples of the new api are provided in the detailed design of > > my proposal. Users use it just like pulsar's existing send functionality, > > without the need to introduce additional encapsulation implementations. > > > > > > 4. Of course, the changes made in this proposal do not actually change > the > > existing pulsar api, but rather wrap it internally. > > > > For example, request api. Call the existing send function directly, get > the > > request MessageID, and wait for the reply response within the timeout > > period. The new ack api simply sends a reply result to the broker, which > > then sends it to the client, after which the existing ack api is called > > directly. > > > > > > Thanks, > > sinan > > > > > > Lari Hotari <lhot...@apache.org>于2024年8月8日 周四23:42写道： > > > > > Thanks for the proposal! > > > > > > Instead of modifying the existing Pulsar client library, I think it's > > > better to create a separate library. The request-reply / rpc model can > be > > > implemented on top of the Pulsar client instead of making the support > for > > > request-reply a first class citizen of the client API. > > > There's an example of a Pulsar based RPC framework at > > > https://github.com/streamnative/pulsar-recipes/tree/main/rpc . > > > > > > We'd like to keep the Pulsar client library API as stable as possible > and > > > without increasing the size of it. The RPC library could be considered > as a > > > plugin or an add-on if we were to make it available in the Apache > Pulsar > > > project. I'll be happy to support this type of design. > > > > > > -Lari > > > > > > > > > On 2024/08/08 15:09:17 SiNan Liu wrote: > > > > Hi all. > > > > > > > > I drafted a proposal to support for request-reply model that > implements > > > RPC > > > > calls in pulsar. > > > > > > > > https://github.com/apache/pulsar/pull/23143 > > > > I'm looking forward to hearing from you. > > > > > > > > > > > > Thanks, > > > > sinan > > > > > > > >
