You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
In v5.4.1, establishing the database connection pool was moved from the run-phase (where problems are retried) to the register-phase (which can cause a pipeline to fail to start).
This was done as a part of mitigating a connection leak caused by a new connection pool being instantiated for each invocation of the scheduler (an anti-pattern of the Sequel library we use).
The effect of moving from run-phase to register-phase is that if an instance cannot connect while a pipeline is starting, manual intervention is required to get the pipeline running again (e.g., restarting the Logstash process or modifying the pipeline definition so that auto-reload will kick in); the pipeline cannot self-recover from a transient error if that error occurs during pipeline startup.
I believe we should restore the prior behavior of establishing the connection pool in the run-phase, and to continue to avoid closing the connection pool until the plugin is closed (at shutdown). This would allow us to pull-forward the prior behavior of retrying initial-connection failures while avoiding re-creating the connection leak.
The text was updated successfully, but these errors were encountered:
In v5.4.1, establishing the database connection pool was moved from the run-phase (where problems are retried) to the register-phase (which can cause a pipeline to fail to start).
This was done as a part of mitigating a connection leak caused by a new connection pool being instantiated for each invocation of the scheduler (an anti-pattern of the Sequel library we use).
The effect of moving from run-phase to register-phase is that if an instance cannot connect while a pipeline is starting, manual intervention is required to get the pipeline running again (e.g., restarting the Logstash process or modifying the pipeline definition so that auto-reload will kick in); the pipeline cannot self-recover from a transient error if that error occurs during pipeline startup.
I believe we should restore the prior behavior of establishing the connection pool in the run-phase, and to continue to avoid closing the connection pool until the plugin is closed (at shutdown). This would allow us to pull-forward the prior behavior of retrying initial-connection failures while avoiding re-creating the connection leak.
The text was updated successfully, but these errors were encountered: