Hi, Asaf.
Maybe?
>
> client.update(ConnectionInfo.builder()
> .setServiceUrl()
> .set...()
> .build())
Yes, This is clearer.
Thanks,
Baodi Shi
在 2023年2月7日 23:48:03 上，Asaf Mesika 写道：
> Oh, thanks Baodi - now I unders
Oh, thanks Baodi - now I understand what he meant by "calling rebuild".
I agree, it's not very intuitive.
Maybe?
client.update(ConnectionInfo.builder()
.setServiceUrl()
.set...()
.build())
On Mon, Feb 6, 2023 at 2:39
I thought about it for a moment, and this is not a good idea.
Using newBuild may be understood by the user as recreating the client
object. It is still intuitive to add the `updateXXX` method.
Thanks,
Baodi Shi
在 2023年2月5日 23:01:57 上，Asaf Mesika 写道：
> Can you please write rebuild example?
>
Can you please write rebuild example?
On Sun, Feb 5, 2023 at 4:05 PM Baodi Shi wrote:
> >
> > Not completely different IMO. When we want to update the service URL,
> >
> > we usually want to connect to another cluster. However, the cluster
> >
> > could have configured authentication, TLS for se
>
> Not completely different IMO. When we want to update the service URL,
>
> we usually want to connect to another cluster. However, the cluster
>
> could have configured authentication, TLS for security, but we cannot
>
> guarantee two clusters share the same TLS certificates or
>
> authenticatio
Ok, makes sense.
On Thu, Feb 2, 2023 at 4:02 PM Yunze Xu
wrote:
> Not completely different IMO. When we want to update the service URL,
> we usually want to connect to another cluster. However, the cluster
> could have configured authentication, TLS for security, but we cannot
> guarantee two c
Not completely different IMO. When we want to update the service URL,
we usually want to connect to another cluster. However, the cluster
could have configured authentication, TLS for security, but we cannot
guarantee two clusters share the same TLS certificates or
authentication configs. I think w
Ok, the last two methods IMO are a completely different topic.
I wonder what the maintainers think about this.
On Mon, Jan 30, 2023 at 4:16 AM Yunze Xu
wrote:
> In summary, the core issue is that ServiceUrlProvider could be
> misused. A user might want to implement its own ServiceUrlProvider by
In summary, the core issue is that ServiceUrlProvider could be
misused. A user might want to implement its own ServiceUrlProvider by
changing the returned value of `get` method but it actually does not
work. The built-in implementations like AutoFailover actually work by
these `updateXXX` methods.
Yunze - in summary - your proposal is to get rid of the ServiceUrlProvider
right? You just want to have setServiceUrl on the client instead?
On Wed, Jan 25, 2023 at 2:03 PM Yunze Xu
wrote:
> It makes sense to me. So the better way is still providing the
> `updateXXX` methods to `PulsarClient`.
It makes sense to me. So the better way is still providing the
`updateXXX` methods to `PulsarClient`. As for how to detect the
connection info (e.g. service URL) changes, it's determined by the
user's implementation. For example, the current AutoClusterFailover
polls with a fixed interval.
We can
If I understand correctly, the idea of having the ability to change
serviceUrl is to support switching over between clusters dynamically?
If that is the case, doesn't it make sense that it will trigger the change
to the client instead of the client polling it and check it self if
something has chan
Yes. The poll happens in the client's internal thread.
Thanks,
Yunze
On Sun, Jan 22, 2023 at 6:56 PM Asaf Mesika wrote:
>
> and the client will poll the ConnectInfoProvider and check if something was
> changed?
>
> On Fri, Jan 20, 2023 at 11:19 AM Yunze Xu
> wrote:
>
> > > I think the `updateSe
and the client will poll the ConnectInfoProvider and check if something was
changed?
On Fri, Jan 20, 2023 at 11:19 AM Yunze Xu
wrote:
> > I think the `updateServiceUrl` is not the initial purpose of exposing to
> the Client API.
>
> I agree. We might need an API like
>
> ```java
> ClientBuilder
> I think the `updateServiceUrl` is not the initial purpose of exposing to the
> Client API.
I agree. We might need an API like
```java
ClientBuilder serviceUrlProvider(ServiceUrlProvider
serviceUrlProvider, Duration interval)
```
But not only the service URL, as you can see, the
`AutoClusterFa
Is it better to introduce a service URL detect interval to the service URL
provider?
I think the `updateServiceUrl` is not the initial purpose of exposing to
the Client API.
It looks like users just provide the interval of checking whether the
service URL is changed.
The Pulsar client will check i
Hi, Yunze:
Obviously, the `ServiceUrlProvider` config is redundant.
>
Agree. In fact, The client already provides the updateServiceUrl method,
which the user can use to implement a dynamic update service URL. As for
how the user implements it and how to close his resources, I think it can
be lef
Hi all,
Currently we have a `ServiceUrlProvider` interface to configure when
constructing a PulsarClient in `ClientBuilder#serviceUrlProvider`.
>From the beginning, I thought the `getServiceUrl` method is called
each time the service URL is used, e.g. topic metadata lookup.
However, the `getServic
18 matches
Mail list logo
