Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Erroneous WARNING message after every schedule firing #9

Open
oliverlockwood opened this issue Aug 9, 2017 · 4 comments
Open

Erroneous WARNING message after every schedule firing #9

oliverlockwood opened this issue Aug 9, 2017 · 4 comments

Comments

@oliverlockwood
Copy link
Contributor

See #2 (comment).

The log message "Couldn't cancel" appears every time a schedule is triggered, because we delete from the scheduler topic after.

What happens is we send the null to the scheduler topic, then we process that as a Cancel (to support explicit deletes, and to remove the schedule from the actors state) but the call to cancel fails since the event triggering has already fired

We still want some kind of warning if we fail to cancel something when it should have actually been cancellable, but we don't want false positive warnings in the mainline.

@oliverlockwood oliverlockwood mentioned this issue Aug 9, 2017
2 tasks
@oliverlockwood
Copy link
Contributor Author

This effectively this is a state machine...

  • SCHEDULED
  • FIRED
  • CANCELLED

and we need to differentiate between transitions direct from SCHEDULED to CANCELLED and those from FIRED to CANCELLED.

(At the moment, we just have two states: SCHEDULED and CANCELLED, denoted by presence or absence in the Akka scheduler. )

@paoloambrosio-skyuk
Copy link
Contributor

The state machine would get reset at every restart, not being able to tell if the delete was from an explicit delete or the scheduler firing.

@oliverlockwood
Copy link
Contributor Author

I guess that's a window condition where something has been deleted or fired, but Kafka compaction's not yet happened?

We probably want to configure (and document the need to configure!) a short compaction delay and a short delete retention period to minimise the impact of that?

@paoloambrosio-skyuk
Copy link
Contributor

We can probably come up with a strategy that minimizes it.

I disagree that this is a bug though. It was designed that way knowing that it would happen... MVP

@dmine4 dmine4 added this to the Sprint 13 milestone Sep 12, 2017
@dmine4 dmine4 removed this from the Sprint 13 milestone Oct 9, 2017
@nwootton nwootton removed the ready label Jul 10, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

7 participants