[improve] [pip] PIP-371: Support for request-reply model that implements RPC calls#23143
Closed
Denovo1998 wants to merge 4 commits intoapache:masterfrom
Closed
[improve] [pip] PIP-371: Support for request-reply model that implements RPC calls#23143Denovo1998 wants to merge 4 commits intoapache:masterfrom
Denovo1998 wants to merge 4 commits intoapache:masterfrom
Conversation
github-actions
bot
added
PIP
doc-required
Member
|
Closing this PR since the PIP proposal hasn't gained required support in the discussion thread. If the situation changes, this PR can be reopened. |
lhotari
changed the title
lhotari
changed the title
15 tasks
Contributor
Author
|
PIP-371 implementation code: #23194 If you are interested, you can look at it. |
1 task
1 task
liangyepianzhou
pushed a commit
to apache/pulsar-java-contrib
that referenced
this pull request
Dec 6, 2024
…ulsar client (#6) **Feedback is not positive due to PIP-371.** apache/pulsar#23143 apache/pulsar#23194 **We need to implement this distributed RPC framework in a way that does not intrude into the pulsar core library. Therefore, we need to use two topics, one is the request topic and the other is the reply topic. The client side sends RPC requests to the request topic, the server side receives request message and performs customized processing, and finally sends them to the reply topic. The client receives the reply message and returns.** ### Motivation <!-- Explain here the context, and why you're making that change. What is the problem you're trying to solve. --> As we known，Pulsar's current **asynchronous** publish-subscribe model serves well for decoupled message distribution, but it lacks a native mechanism for handling **synchronous** interactions typical of Remote Procedure Calls (RPC). This request-reply model can greatly enhance the utility of Pulsar. We can then use Pulsar as RPC. Why would we use Pulsar for this RPC call? - **Implement RPC using Apache Pulsar. Requests can be sent through a client, received by one or more servers and processed in parallel. Finally, the server returns all processing results after processing, and the client can perform summary and other operations after receiving them.** - **This proposal to achieve the function is `request`. `Request` and existing send function of pulsar can be mixed to same topic. 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.** - You can directly use Pulsar's own delaying messages, that is, you can execute RPC regularly. - You can directly use Pulsar's own load balancing mechanism. - You can directly use Pulsar's own message consumption throttling mechanism. - You can directly use Pulsar's own expansion and contraction mechanism. - You can directly use Pulsar's own message call tracking, monitoring, and logging mechanisms. ### Modifications 
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Motivation
As we known，Pulsar's current asynchronous publish-subscribe model serves well for decoupled message distribution, but it lacks a native mechanism for handling synchronous interactions typical of Remote Procedure Calls (RPC).
This request-reply model can greatly enhance the utility of Pulsar. We can then use Pulsar as RPC.
Modifications
Documentation
docdoc-requireddoc-not-neededdoc-completeMatching PR in forked repository
PR in forked repository: