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

Yes, I think the issue has been fixed. Since only found this issue
yesterday which might be a race condition,
but can't confirm at that time, Demogorgon314 took a lot of effort to 100%
confirm the issue. And share the context and PR today.

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

It's not a blocker for 2.10. And we also testing this part these few days
to ensure that these changes do not introduce new problems.
You can see nodece has tested it in pulsarctl and push the fix
https://github.com/apache/pulsar/pull/14297
The rationale for these changes, I think it starts from this PR
https://github.com/apache/pulsar/pull/13666
This is the only one example, we have seen the same issue again and again.
After #13666 get merged,
The contributors found there are many places that might also have the same
problem.

Thanks,
Penghui

On Tue, Feb 15, 2022 at 7:07 PM Lari Hotari <lhot...@apache.org> wrote:

> 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