Thanks for the feedback Konstantin!
Good to hear that.
As far as the Trigger DSL is concerned,
it is not currently in the master but it will come soon.
Kostas
> On Oct 12, 2016, at 6:05 PM, Konstantin Knauf
> wrote:
>
> Hi all,
>
> thank you for looping me in. Because of the memory leak we
Hi all,
thank you for looping me in. Because of the memory leak we first
experienced we have built a work-around, which did not need to delete
timers and are still using it. So for us, I think, this would currently
not be a problem. Nevertheless, I think, it is a strong limitation if
custom trigge
Hi all,
This thread has been dormant for some time now.
Given that this change may affect user code, I am sending this as a
reminder that the discussion is still open and to re-invite anyone who
may be affected to participate.
I would suggest to leave it open till the end of next week and then,
+Konstantin Knauf looping you in directly
because you used the "delete timer" feature in the past and even did some
changes to the timer system. Are you still relying on the fact that deleted
timers are actually deleted.
The main reason for wanting to get rid of delete timer is IMHO that
deleting
What are the use cases where you actually need to delete a timer? How
about we only let users delete timers which they created themselves?
I guessing most of these use cases will be obsolete with the new
Trigger DSL because the trigger logic can be expressed more easily. So
+1 for removing the del
Hi all,
As the title of this email suggests, I am proposing to remove the methods
deleteProcessingTimeTimer(long time) and deleteEventTimeTimer(long time)
from the WindowOperator.Context. With this change, registered timers that
have nothing to do (e.g. because their state has already been clea
