+1 (non-binding)
Thanks,
Baodi Shi
> 2022年11月18日 17:02,Enrico Olivelli 写道:
>
> +1 (binding)
>
> Enrico
>
> Il giorno ven 18 nov 2022 alle ore 08:34 PengHui Li
> ha scritto:
>>
>> +1
>>
>> Penghui
>>
>> On Fri, Nov 18, 2022 at 1:40 AM Matteo Merli wrote:
>>
>>> +1
>>>
>>>
>>> --
>>> Ma
rint when the variable is not
> set?
>
> 5. Regarding Test Plan
> * I would add: Validate the test of autoAck=false still works (you haven't
> broken anything)
> * I would add: Validate existing ProcessingGuarantee test for AtMostOnce,
> AtLeastOnce, ExactlyOnce still wo
then delete it.
>>> 2. For `PulsarSinkAtLeastOnceProcessor` and
>>> `PulsarSinkEffectivelyOnceProcessor`, if `NONE` is configured, it defaults
>>> to ATLEAST_ONCE.
>>> 3. Need to let users know the behavior when they call `record.ack()` inside
>>> the fun
the following 2~3 release. And
> then delete it.
> 2. For `PulsarSinkAtLeastOnceProcessor` and
> `PulsarSinkEffectivelyOnceProcessor`, if `NONE` is configured, it defaults
> to ATLEAST_ONCE.
> 3. Need to let users know the behavior when they call `record.ack()` inside
> the function im
it in the code.
>>> And documented clearly it's deprecated for the following 2~3 release. And
>>> then delete it.
>>> 2. For `PulsarSinkAtLeastOnceProcessor` and
>>> `PulsarSinkEffectivelyOnceProcessor`, if `NONE` is configured, it defaults
>>> to ATLEAST_
Hi Pulsar community,
I open a https://github.com/apache/pulsar/issues/15560 for Function add NONE
delivery semantics
Let me know what you think.
Thanks,
Baodi Shi
## Motivation
Currently Function supports three delivery semantics, and also provides autoAck
to control whether to automatical
+1
Thanks,
Baodi Shi
> 2022年5月11日 16:0956,Enrico Olivelli 写道:
>
> +1 (binding)
>
> Enrico
>
> Il giorno mer 11 mag 2022 alle ore 08:28 Zixuan Liu
> ha scritto:
>>
>> +1(non-binding)
>>
>> Thanks,
>> Zixuan
>>
>> On 2022/04/26 12:07:32 guo jiwei wrote:
>>> Hi community:
>>> In PIP-39
>>>
l website document is:Whether or not the
framework acknowledges messages automatically.
For users, sink is also part of the function framework.
Thanks,
Baodi Shi
> 2022年5月10日 09:1407,Baozi 写道:
>
> Thanks for this detailed discussion about processing guarantee and ack.
> These two set
when USER sets
> ATLEAST_ONCE/EFFECTIVELY_ONCE and AUTO_ACK=true. I don't think the
> JavaInstanceRunnable can ack for use under these cases. So there should be
> some check to ban user submit function with such configs.
>
>
>
> On 2022/05/09 09:02:12 Baozi wrote:
>&
Hi, guys:
I found out that autoAck configuration in function framework now affects
Delivery semantics, and make it difficult for users to understand. Refer to the
following two scenarios.
1. If the user understands that the semantics of Guarantees shall prevail
If the user set Guarantees == AT
Congrats !
Thanks,
Baozi
> 2022年5月5日 08:4032,PengHui Li 写道:
>
> Congrats
ll tests by default. What's the reason?
>>
>> Test retries are enabled precisely because some tests are flaky.
>>
>> Thanks,
>> Michael
>>
>>
>> On Tue, Mar 8, 2022 at 7:57 AM Baozi
>> wrote:
>>>
>>> Good job!
>>
Good job!
I see. Now we retry all tests by default. What's the reason?
The process I understand is:
We don't need to retry the unit test. Once the test fails, let the job fail.
The difference is that new or modified tests need to be tested many times. As
long as there is one failure, the job wi
Thank for your reply. I have some different viewpoint. Please have a look.
> I am not sure that this helps.
> You can still be very lucky and unfortunately many times the impact is on
> other tests, not the new tests.
Yes, that cannot avoid other unit tests affected by this PR. However, the
stab
14 matches
Mail list logo