Re: How to isSet() check for a Timer

[Kenneth Knowles <ke...@apache.org>]

There is not a way to check if a timer has been set. It would be a
different & more expensive protocol if that API were available. Timers are
deliberately a "blind write" API. The best approach today is just what you
said - add a ValueState<Boolean>. But that negates the performance benefits
of the API design.

But your use case is actually probably many uses of timers. I'm adding the
dev list to broadcast the use case. It probably makes sense to have a "set
if unset" API and/or a "set to the minimum of current time and this new
time" API, both still "blind writes".

Kenn



On Fri, Nov 2, 2018 at 8:55 PM Reza Ardeshir Rokni <ra...@gmail.com>
wrote:

> Hi,
>
> I have a need to set an alarm in both the Element DoFn as well as the
> OnTimer code block. I need to ensure that I do not overwrite a already set
> timer, is there a way to check if a Timer has been set?
>
> One thought was to use a ValueState<Boolean> which I can manually set /
> unset as part of the operations. Thoughts?
>
> Cheers
> Reza
>

Re: How to isSet() check for a Timer

[Kenneth Knowles <kl...@google.com>]

What I mean by "blind writes" is that the runner would have to have a
backing service that supports the operation. Using a hidden ValueState
would be a way to automatically support the APIs, but I think they could be
implemented at lower cost without a state read. I'm willing to be wrong
about the perf concerns; easier if I am.

Kenn

On Fri, Nov 2, 2018 at 9:12 PM Reuven Lax <re...@google.com> wrote:

> Those apis might make sense, but I'm not sure how they would be"blind
> writes." I assume we would implement them by adding a hidden ValueState.
>
> On Fri, Nov 2, 2018, 11:01 PM Kenneth Knowles <kenn@apache.org wrote:
>
>> There is not a way to check if a timer has been set. It would be a
>> different & more expensive protocol if that API were available. Timers are
>> deliberately a "blind write" API. The best approach today is just what you
>> said - add a ValueState<Boolean>. But that negates the performance benefits
>> of the API design.
>>
>> But your use case is actually probably many uses of timers. I'm adding
>> the dev list to broadcast the use case. It probably makes sense to have a
>> "set if unset" API and/or a "set to the minimum of current time and this
>> new time" API, both still "blind writes".
>>
>> Kenn
>>
>>
>>
>> On Fri, Nov 2, 2018 at 8:55 PM Reza Ardeshir Rokni <ra...@gmail.com>
>> wrote:
>>
>>> Hi,
>>>
>>> I have a need to set an alarm in both the Element DoFn as well as the
>>> OnTimer code block. I need to ensure that I do not overwrite a already set
>>> timer, is there a way to check if a Timer has been set?
>>>
>>> One thought was to use a ValueState<Boolean> which I can manually set /
>>> unset as part of the operations. Thoughts?
>>>
>>> Cheers
>>> Reza
>>>
>>

Re: How to isSet() check for a Timer

[Reuven Lax <re...@google.com>]

Those apis might make sense, but I'm not sure how they would be"blind
writes." I assume we would implement them by adding a hidden ValueState.

On Fri, Nov 2, 2018, 11:01 PM Kenneth Knowles <kenn@apache.org wrote:

> There is not a way to check if a timer has been set. It would be a
> different & more expensive protocol if that API were available. Timers are
> deliberately a "blind write" API. The best approach today is just what you
> said - add a ValueState<Boolean>. But that negates the performance benefits
> of the API design.
>
> But your use case is actually probably many uses of timers. I'm adding the
> dev list to broadcast the use case. It probably makes sense to have a "set
> if unset" API and/or a "set to the minimum of current time and this new
> time" API, both still "blind writes".
>
> Kenn
>
>
>
> On Fri, Nov 2, 2018 at 8:55 PM Reza Ardeshir Rokni <ra...@gmail.com>
> wrote:
>
>> Hi,
>>
>> I have a need to set an alarm in both the Element DoFn as well as the
>> OnTimer code block. I need to ensure that I do not overwrite a already set
>> timer, is there a way to check if a Timer has been set?
>>
>> One thought was to use a ValueState<Boolean> which I can manually set /
>> unset as part of the operations. Thoughts?
>>
>> Cheers
>> Reza
>>
>