> I would invest more time in:
> - monitoring tools (tools to detect quickly stuck consumers)
> - circuit breakers (fast fail/shut the door to consumers/producers
> that don't behave correctly)
> - guard rails (limits to clients to prevent them to exhaust the
resources on the brokers)
I agree
Hi,
I am starting discussion for PIP-241: TopicEventListener / topic events for
the BrokerService.
PIP issue: https://github.com/apache/pulsar/issues/19224
### Motivation
Some Protocol Handlers may need to know about the topic-specific events to
update internal caches and/or state.
These
The task to optimize the code that calls Jackson is handled by PR
https://github.com/apache/pulsar/pull/19160 as a preparation. Please review
since I will merge that and consider lazy consensus unless changes are
requested.
In the Pulsar master code base, we are already at Java 17. It's time
Gradle Enterprise build scans is now in use for branches in apache/pulsar . For
example, the build scan for master branch can be accessed for the 60+ maven
build runs from the GitHub Actions workflow run build summary view.
master branch build listing:
I have the following suggestions:
1. This configuration item should be dynamically updated in the Pulsar process,
only as a means of troubleshooting when problems occur
2. This configuration item should be turned off by default to avoid impact on
performance
Yubiao,
thanks for sharing your problem and a proposal, this is very helpful
for the community to get in touch with the pain of Pulsar
users/administrators.
In my experience if a "subscription is stuck", the problems are:
* the client has some problems (bug in the client/misconfiguration
