Thanks for the detailed reply, Penghui.

> And, for the new metadata API, we found an issue that will introduce the
> cache inconsistent issue,
> we are working on a fix, it should be a release blocker, otherwise,
> 2.10 will not able to use.

Was this about the issue which this PR 
https://github.com/apache/pulsar/pull/14283 resolved (since it is merged)?

I have the feeling that some past problems haven't been analyzed properly 
before deciding on the solution. There seems to be an understanding that 
switching from synchronous programming model to asynchronous programming model 
solves problems on its own. Before making such changes, I would expect that the 
issue is shared with the community and the assumptions about the problem and 
the planned solution are also shared.

I am referring to PRs such as https://github.com/apache/pulsar/issues/14013 
where the only description of the motivation for the change is that 
"PersistentTopicsBase has some sync methods. Decide to make them async." . 
Would it be possible to improve the description on such changes since those 
changes are included in Pulsar 2.10.0 release?
There seem to be about 20 recent PRs in total which are about sync->async 
changes: https://github.com/apache/pulsar/pulls?q=is%3Apr+is%3Aopen+async
What was the rationale for these changes?

> I'm doing my best to follow PIP 47, but when seeing a potential break
> change, I need to confirm it.
> After all the potential break changes have been confirmed and fixed, I will
> start the vote thread.

The main concern I have about 2.10.0 release is that since we haven't branched 
out branch-2.10 as it is defined in PIP-47. There are more PRs for new changes 
coming in daily (such as the sync-async changes) which can cause instability in 
Pulsar. 

Who can share more context about the sync->async changes? It is also necessary 
for Pulsar 2.10.0 release notes since the sync->async changes are included in 
the release. Why were these changes made?

BR,

-Lari

Reply via email to