Lari, I think there is a big miss. This issue is not _just_ for admin REST
API calls. It exists for every produce/consume client as well as in most
cases, the lookup service being used is the HTTPLookupService leading to
the same issue as you are mentioning for admin API calls. I've left a
comment
On 2024/02/13 06:46:29 Girish Sharma wrote:
> Personally, while this may be a much cleaner approach or may be not solve
> the core issue at all, it is not what we are trying to achieve with our
> PIP, which is basically only a PIP due to configuration changes involved,
> but actually is a bug fix f
Hello Lari,
On Tue, Feb 13, 2024 at 12:04 PM Lari Hotari wrote:
> Thanks for linking to the PIP-95 implementation PR #12056 [1]. I wasn't
> aware that it has been implemented.
>
> That PR is what I thought that was missing. It is the implementation to
> achieve what PIP-61 described as "only ret
Thanks for linking to the PIP-95 implementation PR #12056 [1]. I wasn't aware
that it has been implemented.
That PR is what I thought that was missing. It is the implementation to achieve
what PIP-61 described as "only return the corresponding service URL" and the
PIP-95 design of "use a uniqu
Hi,
I raised this PR to support blue-green migration for cpp client.
PR: https://github.com/apache/pulsar-client-cpp/pull/402
Thanks,
Heseung
On Wed, Feb 7, 2024 at 2:28 PM Heesung Sohn wrote:
> Hi,
>
> Yes, I am currently working on C++ client update for the blue-green
> migration support.
>
Reply inline, and also replied to the GH comment.
On Mon, Feb 12, 2024 at 9:37 PM Lari Hotari wrote:
> The confusing detail is that in PIP-61 [1], the alternative that has been
> implemented in the Pulsar code base has been marked as the rejected
> alternative ("Return all advertised listeners(r
The confusing detail is that in PIP-61 [1], the alternative that has been
implemented in the Pulsar code base has been marked as the rejected alternative
("Return all advertised listeners(rejected)"). The preferred and proposed
alternative "Only return the corresponding service URL" was never im
Thanks for starting the PIP.
I added some thoughts in this comment:
https://github.com/apache/pulsar/pull/22039/files#r1486372582
Expanding my comment in the PR here:
It would be interesting to learn why advertised listeners weren't implemented
as they had been designed. We wouldn't have this
Dear Apache Pulsar Community,
I hope this message finds you well. I wanted to take a moment to extend my
congratulations to every one of you on the launch of the 3.2.0 release.
While the detailed release notes provide an exhaustive list of the changes,
I believe it would greatly benefit our users
