+1 to this if can be natively supported in pulsar(across programming languages). Its a useful capability in messaging.
https://www.enterpriseintegrationpatterns.com/patterns/messaging/RequestReply.html On Fri, 9 Aug 2024 at 9:05 AM, SiNan Liu <liusinan1...@gmail.com> wrote: > 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 > > > > > > > > > > > >
