[improve][broker][PIP-384] Decouple Bookkeeper client from ManagedLedgerStorage and enable multiple ManagedLedgerFactory instances - #23313
Conversation
4dd0759 to
599224c
Compare
599224c to
780f550
Compare
| * @return storage class instance, or empty if not found | ||
| */ | ||
| BookKeeper getBookKeeperClient(); | ||
| Optional<ManagedLedgerStorageClass> getManagedLedgerStorageClass(String name); |
There was a problem hiding this comment.
This method is hard to understand. From the perspective of customizing a managed ledger storage, what I want to know is that when could this method be called and how could the name be.
It seems that the name comes from ManagedLedgerConfig#storageClassName. But how could this config be changed?
There was a problem hiding this comment.
It seems that it can only be set via the topic policies.
There was a problem hiding this comment.
This PR doesn't consider how the ManagedLedgerStorage implementation configures the default value. It's possible to override the storage class name at namespace or topic level in persistence policies.
| v -> transactionMetadataStoreProvider.openStore(tcId, pulsarService.getManagedLedgerFactory(), v, | ||
| v -> transactionMetadataStoreProvider.openStore(tcId, | ||
| pulsarService.getManagedLedgerStorage().getManagedLedgerStorageClass(v.getStorageClassName()) | ||
| .get().getManagedLedgerFactory(), v, |
There was a problem hiding this comment.
NPE will happen if getManagedLedgerStorageClass returns empty. This case is not handled well
There was a problem hiding this comment.
That's correct. This could be improved.
…gerStorage and enable multiple ManagedLedgerFactory instances (apache#23313)
This PR is partial implementation for "PIP-384: ManagedLedger interface decoupling", #23363.
Motivation
This PR is part of an initiative to clean up and decouple the ManagedLedger interfaces from their current implementation in preparation for Pulsar 4.0. The primary goals are:
This work stems from a community discussion on the Apache Pulsar mailing list: Preparing for Pulsar 4.0: cleaning up the Managed Ledger interfaces
This PR adds supports for multiple ManagedLedger implementations when using a custom ManagedLedgerStorage implementation. The benefit of this is that a Bookkeeper implementation can co-exist with a custom ManagedLedger implementation in the same Pulsar cluster.
Scope
This PR aims to make minimal, focused changes to achieve the decoupling goal. It does not include:
Modifications
managedLedgerStorageClassNametoPersistencePoliciesto control theManagedLedgerFactoryinstance that is used for a particular namespace or topic.storageClassNametoManagedLedgerConfig, this field is read fromPersistencePolicies(namespace or topic policies)ManagedLedgerStorageinterface to support getting aManagedLedgerFactorywith thestorageClassNameManagedLedgerFactoryinstanceDocumentation
docdoc-requireddoc-not-neededdoc-complete