Final messages handling

Owned by Karel Kovářík
Last updated: Nov 20, 2018 by Petr Jůza
2 min read


Relevant if Asynchronous messages feature is used. Introduced in OpenHub 2.1.

This feature is disabled by default. You can enable it by setting ohf.asynch.finalMessages.processingEnabled parameter to true.

Messages that are already processed should not be kept indefinitelly in OpenHub repository, for performance reasons. Therefore, mechanism called "final messages handling" is introduced.

Final message handling job

Messages that are considered final by workflow are periodically fetched by job (org.openhubframework.openhub.core.common.asynch.finalmessage.FinalMessagesProcessingJob) and processed. 

Message is final if it's in one of the following state: OK, FAILED or CANCEL

Enabling message handling job

  • see configuration property ohf.asynch.finalMessages.processingEnabled in OpenHub configuration
  • interval & maximum limit of messages in one job loop can be configured, see parameters
    • ohf.asynch.finalMessages.processingIntervalSec
    • ohf.asynch.finalMessages.iterationMessageLimit

Message processing

Is realized by beans of FinalMessageProcessor type. Generally speaking it can be anything, typical scenario will be some kind of archiving before deleting.

Processing order is defined by Order interface implementation.

Note: duration for keeping messages in OpenHub database can be configured differently per each state, for example ohf.asynch.finalMessages.ok.saveTimeInSec. See OpenHub configuration for configuration properties.

DeleteFinalMessageProcessor

  • default implementation provided in OpenHub, does delete all the messages and other related records in the database
  • can be enabled/disabled by configuration property (ohf.asynch.finalMessages.deleteProcessor.enabled)
  • has defined Order, specified in static final variable.

How to add custom message processor?

  • register bean of type FinalMessageProcessor, preferrably class AbstractFinalMessageProcessor should be extended
  • define custom Order, relevant if multiple processors are registered
  • implement method to process message, FinalMessageProcessor is FunctionalInterface
  • method to process message is invoked in database transaction common for all message processors

Error handling

  • if exception is thrown during message processing, job will continue with another one. In next job iteration the message will be processed again
  • if multiple processors are registered then if one throws exception, processing stops and transaction is rolled back. This mechanism tries to ensure, that messages will be processed with all the processors or none