There is a new finding about it.
https://github.com/apache/bookkeeper/pull/2805 also introduces deadlock in
ZkLedgerUnderreplicationManager.
## ReplicationWorker mechanism
The working mechanism of ReplicationWorker is as follows: it retrieves an
under-replicated ledger, transfers the data of t
> Overall looks good to me.
>
> Only one thing I want to mention, should we use a new way to fix it,
> not only remove the original method?
> Because the issue indeed exists, and we need to fix it.
>
> Thanks,
> Yong
Yes, I would like to use a scheduled task to trigger it.
geValue`. It's a heavy operation
> for
> > > zookeeper.
> > >
> > > And in the pulsar, it introduces a deadlock after implementing the new
> API
> > > LedgerUnderreplicationManager#notifyUnderReplicationLedgerChanged
> > > in PulsarLedgerUnderreplicat
;
> > And in the pulsar, it introduces a deadlock after implementing the new API
> > LedgerUnderreplicationManager#notifyUnderReplicationLedgerChanged
> > in PulsarLedgerUnderreplicationManager. see
> > https://github.com/apache/pulsar/pull/21010.
> >
> > I would suggest you remove unde
lock after implementing the new API
> LedgerUnderreplicationManager#notifyUnderReplicationLedgerChanged
> in PulsarLedgerUnderreplicationManager. see
> https://github.com/apache/pulsar/pull/21010.
>
> I would suggest you remove underReplicatedLedgersChangedCb in Auditor. If
> the user wants to record the metri
nager. see
https://github.com/apache/pulsar/pull/21010.
I would suggest you remove underReplicatedLedgersChangedCb in Auditor. If
the user wants to record the metrics, a scheduled task will be better than
a zk watch event to trigger it.
