Re: Remove UnderReplicatedLedgersChangedCb in Auditor

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

Re: Remove UnderReplicatedLedgersChangedCb in Auditor

> 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.

Re: Data loss problem when DefaultEntryLogger switch to DirectEntryLogger, then switch back to DefaultEntryLogger.

> You should never do this in production. But the user may not know the limitation, they may believe that the switching is compatible, not introduce some problems. > BTW do you have a possible solution? see https://github.com/apache/bookkeeper/pull/4041

Re: Data loss problem when DefaultEntryLogger switch to DirectEntryLogger, then switch back to DefaultEntryLogger.

I am concerned about a possible scenario where a user tries to use DirectIO, runs it for a period of time, and experiences some problem on the bookie server side, but is unsure of the cause and suspects it may be related to DirectIO. As a result, the user disables DirectIO and restarts. In this

Re: Improve DefaultEntryLogger read performance

The PR link: https://github.com/apache/bookkeeper/pull/4038

Re: [ANNOUNCE] New committer Wenbing Shen

Wenbing, Congratulatiton! On 2023/07/08 12:39:14 Enrico Olivelli wrote: > Hello Bookkeepers, > > The Project Management Committee (PMC) for Apache BookKeeper > has invited Wenbing Shen to become a committer and we are pleased > to announce that they have accepted. > > Being a committer enables

Re: The CI tests didn't cover bookkeeper V2 protocol.

I submit https://github.com/apache/bookkeeper/pull/3794 for it. Please help to view it when you are in inconvenient.

Re: CI shows successfully but the tests actually has errors

> Hi Yong, > Thanks for finding this critical issue. I think it's dangerous to > merge new PRs before the CI is fixed, because we can't ensure whether > the new PRs introduces bugs. +1

Re: The CI tests didn't cover bookkeeper V2 protocol.

> According to the original PR's motivation > , we wrapped a Netty > allocator > and want to configure something through bookkeeper. > So the user will use our customized allocator and need to obey the rules > we introduced. Then the Netty's

Re: The CI tests didn't cover bookkeeper V2 protocol.

> Make sense. > There are second level config for the memory detection. The first level is > netty jvm param `-Dio.netty.leakDetection.level`, the second level is > bookkeeper config `AbstractConfiguration#setAllocatorLeakDetectionPolicy`. > > If the second level be config greater than

Re: The CI tests didn't cover bookkeeper V2 protocol.

> IMO, this is not expected behavior. In our test, both the client and > server's memory leak detection policy should be gotten from > `-Dio.netty.leakDetection.level` configuration instead of hard code as > `LeakDetectionPolicy.Paranoid` Make sense. There are second level config for the memory

Re: [DISCUSS] BP-61: Revert BP-59 to release ByteBuf using ByteBuf.release() instead of ReferenceCountUtil.safeRelease()

> I think that we must do something, current master branch is not stable. > > My colleague Massimiliano opened this issue > https://github.com/apache/bookkeeper/issues/3751 > > Basically in the current master there is some problem that leads to > Netty BytBuf corruption. > > The problem is

Re: BP-54: Repaired the ledger fragment which ensemble not adhere placement policy.

Could you describe detail. On 2022/08/01 17:00:47 steven lu wrote: > I feel that the code is not the same as the discussion: > https://github.com/apache/bookkeeper/pull/3359

Re: BP-54: Repaired the ledger fragment which ensemble not adhere placement policy.

You means we define api in EnsemblePlacementPolicy, and use SPI to load special implementation? On 2022/07/29 15:10:05 Enrico Olivelli wrote: > I support this feature. > > We should design the changes to the APIs. > We need to change EnsemblePlacementPolicy, that is a pluggable API: > users

Re: BP-54: Repaired the ledger fragment which ensemble not adhere placement policy.

@Enrico