I started the voting process for this PIP
Thanks
Yubiao
On Thu, Jan 19, 2023 at 5:55 PM Haiting Jiang
wrote:
> I agree with Penghui & Xiaolong,
>
> 1. Restarting a service is usually the most common and effective
> option for service maintainers to recover a service and minimize the
> business
I agree with Penghui & Xiaolong,
1. Restarting a service is usually the most common and effective
option for service maintainers to recover a service and minimize the
business loss.
With this subscription unloading, we can reduce the impact
significantly, as unloading topics will affect message wr
Hello Joe and Enrico:
I agree with what you've been emphasizing that we need to fix these issues
at the root cause. During the maintenance of the Go SDK, we have
encountered many stuck problems since version 0.4.0, some of which belonged
to the logic errors handled by the Go SDK itself, and some o
> What kind of problems is this trying to fix?
And why cannot that be solved by client-side fixes?
Yes, most of the issue is from the client side, rarely from the broker.
But the application also needs time to fix the issue to release and deploy
the fix
to the production environment. Unloading the
Inclined to agree with Enrico. If it's a hard problem, it will repeat, and
this is not helping. If it's some race on the client, it will occur
randomly and rarely, and this unload sub will get programmed in as a way of
life.
>If you don't think unloading the subscription can't help anything.
Unl
I agree that if we encounter a stuck consumption issue, we should continue
to find the root cause of the problem.
Subscription unloading is just an option to mitigate the impact first.
Maybe it can mitigate the issue for 1 hour sometimes. Especially in
key_shared subscription. Sometimes it's not a
Il giorno lun 16 gen 2023 alle ore 11:58 r...@apache.org
ha scritto:
>
> I agree with @Enrico @Bo, if we encounter a subscribe stuck situation, we
> must continue to spend more time to locate and fix this problem, which is
> what we have been doing.
>
> But let's think about this problem from anot
I agree with @Enrico @Bo, if we encounter a subscribe stuck situation, we
must continue to spend more time to locate and fix this problem, which is
what we have been doing.
But let's think about this problem from another angle. At this time, a user
in the production environment encounters a consum
Hi Qiang
> 1. How do you handle the race condition when you are trying to unload the
subscription, and the new consumer wants to subscribe to this subscription
at the same time? I'm unsure if it has the race condition. I just want to
remind you about that.:)
These methods `addConsumer`, `removeCo
Hi @Enrico @Bo
> If there is a problem we should spend time on investigating the problem
and not in adding this kind of tools.
You are right. When a user encounters a problem, it often takes a while to
solve the root cause. It is important to provide a tool to recover services
quickly, and cmd 'u
> 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 with
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
somewhere
Hi, Yubiao
I agree with this idea because some users care about the production rate. They
don't want to unload the whole topic to fix the subscription problem.
I've got some questions:
1. How do you handle the race condition when you are trying to unload the
subscription, and the new consumer
Thanks YuBiao Feng:
> We sometimes try to unload the topic to resolve some consumption-stop
> issues. But the unloading topic will also impact the producer side.
This is indeed an interesting thing. In the current production operation
and maintenance, unload is a very frequently used operation. A
Hi community
I am starting a DISCUSS for PIP-240: A new API to unload subscriptions.
PIP issue: https://github.com/apache/pulsar/issues/19187
### Motivation
We sometimes try to unload the topic to resolve some consumption-stop
issues. But the unloading topic will also impact the producer side.
15 matches
Mail list logo
