asafm commented on PR #17041:
URL: https://github.com/apache/pulsar/pull/17041#issuecomment-1239343850
> @asafm Yes, you are right and I understand your concern, but actually, we
can know that which metadata store is configuration store and which stores
broker metadata, just takes a little skill：
>
> In PulsarService.java, code as below:
>
> ```
> localMetadataStore =
createLocalMetadataStore(localMetadataSynchronizer);
>
localMetadataStore.registerSessionListener(this::handleMetadataSessionEvent);
>
> coordinationService = new
CoordinationServiceImpl(localMetadataStore);
>
> if (config.isConfigurationStoreSeparated()) {
> configMetadataSynchronizer =
StringUtils.isNotBlank(config.getConfigurationMetadataSyncEventTopic())
> ? new PulsarMetadataEventSynchronizer(this,
config.getConfigurationMetadataSyncEventTopic())
> : null;
> configurationMetadataStore =
createConfigurationMetadataStore(configMetadataSynchronizer);
> shouldShutdownConfigurationMetadataStore = true;
> } else {
> configurationMetadataStore = localMetadataStore;
> shouldShutdownConfigurationMetadataStore = false;
> }
> ```
>
> Broker metadata store initialized before configuration metadata store, so,
`metadata-store-0` is broker metadata store and `metadata-store-1` is
configuration metadata store
1. Do you find that a reasonable user experience for a Pulsar user? IMO,
they will get quite frustrated and mad when they read that, where all they
wanted to do was to know the metrics of metadata store access.
2. Reiterating my question in the original comment - how of the options I
listed above, what is your goal when breaking down the metadata store metrics?
(see the question in the previous comment)
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
