Skip to end of metadata
Go to start of metadata

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 8 Current »


Integration platform generates application logs and writes records to database.

Application logs

There is Maven property log.folder that specifies target folder for application logs.

Log names are in format logFile_YYYY-MM-DD_N.log, where N is order number unique for each day. If the log file is greater then 10MB then new log file with next order number is created. It's best practice to backup these application logs, at least for 2 months.

Logback offers lot of possibilities where and how log items save to - to file system, to database, send it by emails etc. 

See ohf-logback.xml for default logging configuration.


When we use standard installation with Apache Tomcat server then we have all logs in /srv/project_name/logs/ folder with the the following sub-folders:

  • apache: logs generated by Apache HTTP server
  • j2ee: logs from integration platform
  • tomcat: logs generated by Apache Tomcat

Database

OpenHub stores lot of records to database, namely to these tables (see Data model for more information):

  • message
  • external_call
  • request (it depends on configuration)
  • response (it depends on configuration)

Also database records should be backuped. Remove old records to keep good performance - we remove records older then 2 months usually on our production installations. 

Stop ESB

OpenHub allows to switch to stopping mode where no new asynchronous and/or synchronous requests will be processed, only current asynchronous messages will be finished (messages in states IN_QUEUE, PROCESSING and WAITING_FOR_RES).


Synchronous requests which should reject incoming calls are recognized by input URI. This URI is identified by regular expression defined in the property ohf.uri.inputPatter.

If OpenHub rejects incoming request then exception org.openhubframework.openhub.api.exception.StoppingException is thrown.

Technical implementation:

When route starts with specified input URI then HandleMessagePolicy is created. When node is stopped then this policy throws an exception.

For getting information about route type (input, output etc.) use RoudeDefinitionService. Default implementation of this service searchs route type in all implementations RouteTypeResolver.


This functionality is available in admin GUI.

  • No labels