Major
Detail
Detail
Detail
#27015
Logging in KBDataProducerTask should cover error cases better
Logging in tl:KBDataProducerTask is often insufficient in the event of an error. Unfortunately, due to the inherent complexity of distributed applications, problems often occur in the area, but it is especially important to have helpful log messages here.
Improvement
- When the task terminates, it logs at which revisions this happens.
- If exceptions occur, they will always be logged. Even if they are just thrown further afterwards.
- If an exception is propagated, but in turn an exception is thrown in a finally block, none will be suppressed. Both are logged in the end.
- The task logs on level DEBUG, as soon as a further changeset was transmitted.
- The logging in the task was generally extended.
- So that during the task the progress is logged, logging was inserted in tl:TypeFilterRewriter.
- Every minute the current status is logged.
- The interval is configurable.
- For "large" changesets, the number of events is logged in advance.
- The threshold for "large" is configurable. The default value is 1000.
- Every minute the current status is logged.
Code Migration
The class TaskResult.TaskResultsByDateComparator was deleted and replaced by the expression Comparator.comparing(TaskResult::getStartDate).
Test
No test.
Reason: Can only be tested with difficulty. Would need to break random places in tl:KBDataProducerTask and check that all relevant exceptions and data always end up in the log. There are frameworks to check how code behaves when exceptions are thrown at random places. But to include something like that here would be much too complex for the purpose. Therefore neither an automatic test, nor a manual one.