Outputs that cannot be initialized are being tried to initialize constantly #741
Assignees
Milestone
Comments
lennartkoopmann
changed the title
|
We are initialising them lazily because it's much simpler. I am in the process of changing this right now, because when we/3rd party implement outputs that need to hold resources (like network/database connections) we cannot do this anymore and need proper state handling. Won't be fixed in 0.92.x, but in 0.93.0. |
|
What is the state of this issue, @dennisoelkers ? |
dennisoelkers
added a commit
that referenced
this issue
Jan 16, 2015
…ion repeatedly. We do not handle outputs the same way as we do with inputs right now. We don't know which outputs are going to run on which nodes, so we are just starting them lazily when an output's stream is catching a message and they are kept running until the server restarts or the output is deleted. This means that we cannot just flag them as failed, so the approach here is to temporarily refrain from trying to instantiate them after a certain configurable fault count threshold was crossed. The fault count is tracked using an internal counter which is reset after the fault penalty time frame passed (even if the threshold was not crossed). As a plus, fixing output removal, which is actually stopping the output now. Fixes #741
joschi
pushed a commit
that referenced
this issue
Jan 21, 2015
joschi
pushed a commit
to graylog-labs/graylog2-web-interface
that referenced
this issue
Jan 21, 2015
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
When a
MessageOuputis throwing an exception in itsinitializemethod, the server tries to initialize it again for every message that goes through theOutputRouter.The text was updated successfully, but these errors were encountered: