+1
There will be ~70 commits compared to 2.10.3 which I think it's a good
amount of changes.
Thanks,
Nicolò Boschi
Il giorno gio 2 feb 2023 alle ore 07:53 Haiting Jiang <
jianghait...@gmail.com> ha scritto:
> +1, It's about 3 months since the discussion of the 2.10.3 release.
>
> Haiting
>
> O
Hi, Yong
> How about using a blacklist way to restrict it?
It's a great idea. Maybe we can define the rules like `keyword` with regular
expressions.
Best,
Mattison
On Feb 2, 2023, 10:52 +0800, Yong Zhang , wrote:
> Mattison,
>
> I agree with you about restricting the topic name.
>
> How abou
Hi, Yunze
> The topic name character validation is already done by`NamedEntity#checkName`
As Michael mentioned, the `NamedEntity#checkName` just checked the tenant and
namespace.
> But I have a concern that whether we shouldtreat all topics that start with
> the long underscore ("__") as systemto
Hi, Asaf
We are using the regular expression to check the name.
"^[-=:.\\w]*$"
The \w means [A-Za-z0-9_] , which includes underscores.
Best,
Mattison
On Feb 2, 2023, 23:01 +0800, Asaf Mesika , wrote:
> NamedEntity is not allowing underscores - does it make sense?
>
>
>
> On Thu, Feb 2, 2023 at 8:
> If you persisted the message successfully by the producer and the broker
> was terminated before being able to delete the ledger from the metadata
> service?
If the broker is terminated, the consumer won't ack the message, the message
will be re-consume later.
> I recommend having the logic to
Heesung, thanks. That's a good point for multi steps works. But I'm afraid it
will increase the zk pressure and it also needs to handle some corner cases. I
prefer to use a system topic to handle it.
On 2023/01/31 19:05:34 Heesung Sohn wrote:
> On Tue, Jan 31, 2023 at 6:43 AM Yan Zhao wrote:
>
> If we don't want to add more pressure on the metadata store from this
> feature as a requirement,
> I think we can use a system topic as well. Just to confirm, is this the
> direction we are agreeing on?
The design is too generic, I'm afraid not it is not suitable for ledger
deletion.
>
> Usin
There are some cases to trigger it.
1. A cursor be removed.
2. Close the current ledger and create a new ledger.
3. Consumer ack the message, the slowest cursor move forward.
4. User trigger truncateTopic by admin.
I see that this pip is for the internal ledger deletion cases(1-3 above),
and it ap
For these internal requesters,
1. A cursor be removed.
2. Close the current ledger and create a new ledger.
3. Consumer ack the message, the slowest cursor move forward.
How do we prevent these callers from requesting duplicate requests for the
same resources(ledgers) (how do we handle racing cond
+1 (binding)
- validated 1 signature
- validated 1 checksum
- validated source equality from git using diff to observe the
following differences:
$ diff -r pulsar-client-reactive-0.2.0
pulsar-client-reactive-0.2.0-candidate-2-source/
Only in pulsar-client-reactive-0.2.0-candidate-2-source/: .asf.
10 matches
Mail list logo
