-
Notifications
You must be signed in to change notification settings - Fork 3.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
add robustness to avoid crashing on unexepected input #1250
Comments
also mentioned in https://logstash.jira.com/browse/LOGSTASH-1623 |
same idea in https://logstash.jira.com/browse/LOGSTASH-2107 |
I haven't looked into how exceptions are handled in logstash currently, so I'm just spitballing here :) My feeling is, that handling exceptions needs to somehow be centralized - so it can be handled better once - and for all times. I'm sure you are better than me, at designing that in java :) some sort of automatic exception handling that each input, output, filter etc. simply inherits (and can extend if need be), which does something default (and configurable) - like drop the line being worked on to a "failed lines" output - and then just skip and continue. |
related to #2130 (comment) |
the global exception handling issue is #2386 - I will keep this one open to make sure this specific concerned is tracked. |
Any traction on this. It has been open for a long time? |
I am closing this issue and redirecting to #4127. A lot a progress has been made to improve exception handling & reliability and the original issue reported here is not very current anymore. |
this is a followup from issue #1240 - where pre multiline/tv_sec fix shippers were paired with post multiline/tv_sec fix indexers using redis. The indexer was crashing on the tv_sec error because the shipper malformed the event.
should we add robustness to avoid crashing in such a condition?
The text was updated successfully, but these errors were encountered: