-
Notifications
You must be signed in to change notification settings - Fork 592
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
fix: throw instead of silently overwriting timers #8785
Conversation
Here we throw an exception when a timerId was generated that already exists in the timerJobMap. Throwing here will fail when scheduling a new timer or when resubmitting a recurring timer. This should never happen, but we have one heapdump where it looks like it did: #8776
d18f485
to
842988d
Compare
I think we should catch this exception in case re-submitting a recurring timer fails so that we don't kill an actor thread when this happens |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think we should catch this exception in case re-submitting a recurring timer fails so that we don't kill an actor thread when this happens
But I think we already have implemented a failure handling? Basically, the IllegalStateException
is thrown which will be caught in ActorJob#execute()
which may cause to fail the actor but to my understanding, the actor thread will keep running?
So, to me, the question would be if it is okay that the respective actor fails and what would be the impact of it?
What do you think?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM 🚀
bors r+ |
8785: fix: throw instead of silently overwriting timers r=oleschoenburg a=oleschoenburg ## Description Here we throw an exception when a timerId was generated that alreadyexists in the timerJobMap. Throwing here will fail when scheduling a new timer or when resubmitting a recurring timer. This should never happen, but we have one heapdump where it looks like it did: #8776 ## Related issues <!-- Which issues are closed by this PR or are related --> relates to #8776 Co-authored-by: Ole Schönburg <ole.schoenburg@gmail.com>
Build failed: |
bors retry |
8785: fix: throw instead of silently overwriting timers r=oleschoenburg a=oleschoenburg ## Description Here we throw an exception when a timerId was generated that alreadyexists in the timerJobMap. Throwing here will fail when scheduling a new timer or when resubmitting a recurring timer. This should never happen, but we have one heapdump where it looks like it did: #8776 ## Related issues <!-- Which issues are closed by this PR or are related --> relates to #8776 Co-authored-by: Ole Schönburg <ole.schoenburg@gmail.com>
Build failed: |
bors retry |
8785: fix: throw instead of silently overwriting timers r=oleschoenburg a=oleschoenburg ## Description Here we throw an exception when a timerId was generated that alreadyexists in the timerJobMap. Throwing here will fail when scheduling a new timer or when resubmitting a recurring timer. This should never happen, but we have one heapdump where it looks like it did: #8776 ## Related issues <!-- Which issues are closed by this PR or are related --> relates to #8776 Co-authored-by: Ole Schönburg <ole.schoenburg@gmail.com>
Build failed: |
bors retry |
Successfully created backport PR #8826 for |
Successfully created backport PR #8827 for |
Description
Here we throw an exception when a timerId was generated that alreadyexists in the timerJobMap.
Throwing here will fail when scheduling a new timer or when resubmitting a recurring timer.
This should never happen, but we have one heapdump where it looks like it did: #8776
Related issues
relates to #8776
Definition of Done
Not all items need to be done depending on the issue and the pull request.
Code changes:
backport stable/1.3
) to the PR, in case that fails you need to create backports manually.Testing:
Documentation: