-
Notifications
You must be signed in to change notification settings - Fork 1.5k
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 Shutdown behavior for batchprocessor #2537
Fix Shutdown behavior for batchprocessor #2537
Conversation
Codecov Report
@@ Coverage Diff @@
## main #2537 +/- ##
==========================================
- Coverage 91.76% 91.72% -0.05%
==========================================
Files 265 266 +1
Lines 15082 15101 +19
==========================================
+ Hits 13840 13851 +11
- Misses 861 867 +6
- Partials 381 383 +2
Continue to review full report at Codecov.
|
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 am not sure what is the right thing to do here. Do we want every component to protect the ConsumeSignal
, or we want to guarantee from the framework that no calls to ConsumeSignal
come after Shutdown
?
@tigrannajaryan also if this is something we want to do, to reject incoming requests if component is shutting down, we should probably do this in the processorhelper :) |
Yes, that's coming in a future PR. |
fbe6414
to
918b030
Compare
I am going to add protection in helpers so it will be in one place. Components that don't use helper will have to do it themselves. |
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.
Consider to remove build.log?
918b030
to
37ec59b
Compare
Oops. Removed. |
c980f54
to
6c488e4
Compare
I removed most of the original code which was attempting to protect the processor from Consume* calls happening after Shutdown() is called. According to Component contract this should just not happen, so we don't need to protect from it, but instead make sure all components follow the contract (never call Consume* of the next component after Shutdown() returns). This PR now merely ensure batchprocessor follows the contract. The test verifies it. |
if err == configerror.ErrDataTypeIsNotSupported { | ||
return | ||
} | ||
require.NoError(t, err) |
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 know that it sounds strange to have unittest for testing helpers but for this logic is probably good :) Maybe in a separate PR?
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.
There is a TODO to handle other data type later in the file. We can address as part of that TODO (this code may change as a result of that, so I don't want to spend time on it now).
I added a Shutdown() test that does basic verification of the behavior of the Shutdown() function. More verifications can be added later. The test revealed a bug in batchprocessor Shutdown() function which would not wait until all pending data was drained.
6c488e4
to
f123dd2
Compare
Tests restarted. |
…2537) Enable fluentforward receiver in the default ECS/EC2 configuration so users with [docker logging driver](https://docs.docker.com/config/containers/logging/fluentd/) can easily forward their logs through the collector
I added a Shutdown() test that does basic verification of the behavior of the
Shutdown() function. More verifications can be added later.
The test revealed a bug in batchprocessor Shutdown() function which would
not wait until all pending data was drained.