[improve][pip] PIP-418: Determine the behaviors for components that rely on BookKeeper when BookKeeper is not used#24296
Conversation
…ely on BookKeeper when BookKeeper is not used
BewareMyPower
added
type/enhancement
github-actions
bot
added
PIP
doc
| The following components leverages this factory to create their own `BookKeeper` instances: | ||
| - `BookkeeperSchemaStorageFactory`: The default schema registry storage configured by `schemaRegistryStorageClassName` | ||
| - `BookkeeperBucketSnapshotStorage`: A non-default built-in delayed delivery tracker configured by `delayedDeliveryTrackerFactoryClassName` |
There was a problem hiding this comment.
I’m not entirely sure why separate BookKeeper instances are used for these two cases. While this doesn’t directly affect the goal of the proposal, should we consider addressing or revisiting this as part of a broader cleanup?
| | Schema Registry | Fail fast | | ||
| | Delayed Delivery Tracker | Fail fast if it's `BucketDelayedDeliveryTrackerFactory` | | ||
| | Compaction Service | Fallback to a dummy implementation | |
There was a problem hiding this comment.
These three items refer to Pulsar’s default implementations, correct? If users have provided their own plugin implementations, they shouldn’t be affected — is that understanding accurate?
| ```java | ||
| public interface BookkeeperManagedLedgerStorageClass extends ManagedLedgerStorageClass { | ||
| /* ... */ | ||
| BookKeeperClientFactory getBookKeeperClientFactory(); |
There was a problem hiding this comment.
Is it designed to be used by BookkeeperSchemaStorageFactory and BookkeeperBucketSnapshotStorage?
I mean, BookkeeperManagedLedgerStorageClass already has getBookKeeperClient, and should all Pulsar's internal implementations use the same bookkeeper client? Maybe I missed something.
Co-authored-by: Penghui Li <penghui@apache.org>
3 participants
Documentation
docdoc-requireddoc-not-neededdoc-completeMatching PR in forked repository
PR in forked repository: