Skip to content

Conversation

@Denovo1998
Copy link
Contributor

@Denovo1998 Denovo1998 commented Aug 8, 2024

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

  • doc
  • doc-required
  • doc-not-needed
  • doc-complete

Matching PR in forked repository

PR in forked repository:

@github-actions github-actions bot added PIP doc-required Your PR changes impact docs and you will update later. labels Aug 8, 2024
@lhotari
Copy link
Member

lhotari commented Aug 14, 2024

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 lhotari closed this Aug 14, 2024
@lhotari lhotari changed the title [improve] [pip] PIP-371: Support for request-reply model that implements RPC calls [improve] [pip] PIP-xxx: Support for request-reply model that implements RPC calls Aug 14, 2024
@lhotari lhotari changed the title [improve] [pip] PIP-xxx: Support for request-reply model that implements RPC calls [improve] [pip] PIP-371: Support for request-reply model that implements RPC calls Aug 14, 2024
@Denovo1998
Copy link
Contributor Author

PIP-371 implementation code: #23194

If you are interested, you can look at it.

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

![RPC.drawio](https://github.com/user-attachments/assets/91208b7b-7f65-4a22-8bfb-fc3161e4ec18)
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

doc-required Your PR changes impact docs and you will update later. PIP

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants