apache / apache/pulsar

[Bug] How to solve or optimize this problem [Client memory buffer is full]

Open
#17,360 7 comments 0 reactions 0 assignees View on GitHub
Stale type/bug
Dominant language
Java
Stars
15.3k
Forks
3.8k
Avg merge
1d 14h
Merged PRs (30d)
160

Description

### Search before asking

- [X] I searched in the [issues](https://github.com/apache/pulsar/issues) and found nothing similar.

### Version

2.10.1 master

### Minimal reproduce step

When we call the client for a long time, we find that the client is down and cannot send messages.
Then we got an exception while calling the client producer to send messages. (Maybe the frequency of use is too high)
![screen_shot_1661910571587](https://user-images.githubusercontent.com/57656190/187574956-f53ce5b6-d9a1-4335-a19b-c5d842ac1488.png)
Before asking, we have checked the relevant issues #15724 and #15691,but we still don't know how to avoid this situation.
And this is our process of creating producers
![screen_shot_1661911158535](https://user-images.githubusercontent.com/57656190/187576061-a05de317-b233-40c9-a8ab-af69be22b39f.png)
For the configuration of these two parameters(maxPendingMessages and memoryLimit), we set the default values . Btw,The JVM memory of the producer client is 10g and our server memory is 24g.When a problem occurs, out of heap memory is sufficient.
So,how to solve or optimize this problem [Client memory buffer is full]

### What did you expect to see?

Avoid this problem, or recover to the original normal situation when the client hangs up.

### What did you see instead?

Failing

### Anything else?

We sincerely hope to solve this problem,

### Are you willing to submit a PR?

- [X] I'm willing to submit a PR!

Contributor guide

Open the contributing guide

Research direction

Start by reviewing issues #15724 and #15691, then reproduce the long-running, high-frequency producer calls against Pulsar 2.10.1 or master. Compare behavior with the default maxPendingMessages and memoryLimit settings and capture the client exception when the buffer fills. Done means the cause and a verifiable recovery or avoidance path are documented or covered by a focused test.

Written by the indexing model from the issue text.

Assessment

Tech stack
java
Domain
distributed-systems
Issue type
Bug
Difficulty
4/5
Estimated time
3-5 days
Activity status
Stale
Clarity
Needs clarification
Newbie friendliness
25/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.