-
Notifications
You must be signed in to change notification settings - Fork 4.9k
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
Update go-concert to 0.1.0 #23770
Update go-concert to 0.1.0 #23770
Conversation
if err != nil { | ||
l.log.Errorf("Error while stopping filestream logFile reader: %v", 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.
The group now shuts down when the readerCtx
gets cancelled. This is a slight change in semantics, as the reader context was closed in the past only after the taskgroup go-routines have finished (Stop used to wait).
In order to make behavior and signal propagation a little more predictable, the change ensures that we have a clear chain of cancellation contexts:
canceler -> readerCtx -> (taskgroup ctx)
. Before we used to have something like:
canceler -> ctx
canceler -> (taskgroup ctx)
💚 Build Succeeded
Expand to view the summary
Build stats
Test stats 🧪
Trends 🧪Steps errorsExpand to view the steps failures
|
Test | Results |
---|---|
Failed | 0 |
Passed | 46515 |
Skipped | 4776 |
Total | 51291 |
} | ||
} | ||
return nil | ||
}) |
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.
Replaced the for loop with timed.Periodic
. The for loop did not check the state of the context before executing the select statement. Due to select checking channels in random order the ctx.Done()
can be ignored multiple times in the worst case. Switching to Periodic
resolves this issue.
continue | ||
} | ||
connCancel() | ||
l.doRun(ctx) |
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.
moved the body into a separate method, so we can do defer cancel()
to cleanup resources. The handle is created independent of the module and we must cleanup in case the handler panics.
TODO: shall we consider to recover from a panic here or only recover if the handler failed?
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.
Looking at the package net
, we probably won't see many panics from listener
function. Also, how could we recover from such issues? If anything fails during that function call it requires action from the user, e.g. fixing addresses or changing the protocol. These are problems from those we cannot recover without user interference.
I would only call recover to take care of panics from handler
.
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 would only call recover to take care of panics from handler.
yeah, I did mean the handler. Added Recover
to connectAndRun
Pinging @elastic/agent (Team:Agent) |
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.
Thank you! Great improvements!
Interesting. Test run was green, but pipeline seems to be aborted near/after the end. Maybe we hit a jenkins maintenance window. |
/test |
1 similar comment
/test |
051d02d
to
5f0b5ab
Compare
…-arm * upstream/master: [Metricbeat][Kubernetes] Extend state_node with more conditions (elastic#23905) [CI] googleStorageUploadExt step (elastic#24048) Check fields are documented for aws metricsets (elastic#23887) Update go-concert to 0.1.0 (elastic#23770) [Libbeat][New Processor] XML Decode (elastic#23678) Fix: bad substitution of API key (elastic#24036) [Filebeat] Add Pensando DFW Module (elastic#21063) [Filebeat] Check if processor is supported by ES version (elastic#23763) Syslog system tests: be more forgiving (elastic#24021)
(cherry picked from commit 342a845)
…dows-7 * upstream/master: (332 commits) Use ECS v1.8.0 (elastic#24086) Add support for postgresql csv logs (elastic#23334) [Heartbeat] Refactor config system (elastic#23467) [CI] install docker-compose with retry (elastic#24069) Add nodes to filebeat-kubernetes.yaml ClusterRole - fixes elastic#24051 (elastic#24052) updating manifest files for filebeat threatintel module (elastic#24074) Add Zeek Signatures (elastic#23772) Update Beats to ECS 1.8.0 (elastic#23465) Support running Docker logging plugin on ARM64 (elastic#24034) Fix ec2 metricset fields.yml and add integration test (elastic#23726) Only build targz and zip versions of Beats if PACKAGES is set in agent (elastic#24060) [Filebeat] Add field definitions for known Netflow/IPFIX vendor fields (elastic#23773) [Elastic Agent] Enroll with Fleet Server (elastic#23865) [Filebeat] Convert logstash logEvent.action objects to strings (elastic#23944) [Ingest Management] Fix reloading of log level for services (elastic#24055) Add Agent standalone k8s manifest (elastic#23679) [Metricbeat][Kubernetes] Extend state_node with more conditions (elastic#23905) [CI] googleStorageUploadExt step (elastic#24048) Check fields are documented for aws metricsets (elastic#23887) Update go-concert to 0.1.0 (elastic#23770) ...
What does this PR do?
Update go-concert to version 0.1.0 and update some code in Beats.
Why is it important?
Uhm... UPDATES \o/
Checklist
- [ ] I have commented my code, particularly in hard-to-understand areas- [ ] I have made corresponding changes to the documentation- [ ] I have made corresponding change to the default configuration files- [ ] I have added tests that prove my fix is effective or that my feature works- [ ] I have added an entry inCHANGELOG.next.asciidoc
orCHANGELOG-developer.next.asciidoc
.