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
When there's an issue interacting with the database while retrieving messages, those issues are currently ignored. This leads to results that are incomplete.
Fail-fast behavior is desired here: when there's a database error, thrown an exception.
It's probably best to make this configurable, to allow administrators to fall back to ignoring errors, for those instances where, for a reason that's currently beyond me, have significant amounts of database issues.
The text was updated successfully, but these errors were encountered:
The property that can be used to control this behavior is archive.ignore-retrieval-exceptions. It's value is a boolean. false, which will be the new default, will cause XMPP errors to be generated, while true restores the old behavior of ignoring errors.
guusdk
added a commit
to guusdk/openfire-monitoring-plugin
that referenced
this issue
Dec 11, 2020
When there's an issue interacting with the database while retrieving messages, those issues are currently ignored. This leads to results that are incomplete.
Fail-fast behavior is desired here: when there's a database error, thrown an exception.
It's probably best to make this configurable, to allow administrators to fall back to ignoring errors, for those instances where, for a reason that's currently beyond me, have significant amounts of database issues.
The property that can be used to control this behavior is archive.ignore-retrieval-exceptions. It's value is a boolean. false, which will be the new default, will cause XMPP errors to be generated, while true restores the old behavior of ignoring errors.
When there's an issue interacting with the database while retrieving messages, those issues are currently ignored. This leads to results that are incomplete.
Fail-fast behavior is desired here: when there's a database error, thrown an exception.
It's probably best to make this configurable, to allow administrators to fall back to ignoring errors, for those instances where, for a reason that's currently beyond me, have significant amounts of database issues.
The text was updated successfully, but these errors were encountered: