CronService: Improve failsafe quality and logging [3]

[mario-kuehne]

Problem Description

The CronService (CronService.java) triggers different methods that might fail and throw exceptions. If an exception is thrown the method does not get scheduled again. Currently a server restart is necessary to achieve that the schedule for that method gets triggered again.

Proposed Change

• Encapsulate every interior of every CronService method (~17 methods) as a CronJob subclass as shown in this PoC: 8e56b0afe4fe5a0eb9ec36abdae9f35041564ee3 The PoC is partly in german, translation needed.
• Remove partly existing logging that is now done by CronJob per default.
• Let more backend methods return the number of processed elements (Integer)?

Acceptance Criteria

Uncaught exceptions must not influence the schedule.

Implementation Details

• See PoC: 8e56b0afe4fe5a0eb9ec36abdae9f35041564ee3

Additional Information

• ~~Investigation necessary: Whole CronService impacted or just the scheduled method that throws an exception?~~ Ticket refined by @StefanKock

[StefanKock]

~~Investigation~~ Known architecture: The timer for a @Schedule method that fails (twice) gets automatically explunged. A workaround pattern is known: You have to annotate the called ejb method with @TransactionAttribute(TransactionAttributeType.REQUIRES_NEW) and catch all RuntimeExceptions. In other products we use injectable Job instances (superclass that does a lot of boilerplate code, also includes logging and checking if the job is activated) per automatic action that is suppose to happen.