Skip to main content
Jump to: navigation, search


Revision as of 15:51, 29 October 2013 by (Talk | contribs) (Design)



  • shall handle thousands of log entries per second
  • log entries shall be quickly accessible based on any combination of server, user, timestamp, log type, duration, status
  • log entries shall be accessible (especially) when an application server is unresponsive
  • log entries shall be available until they are deleted by an admin or admin policy (applied by server automatically)
  • at run-time logging shall be enabled/disabled based on any combination of user, source, and type


id, parent_id, timestamp, user, type_id, duration, status, details (maybe in JSON format)

  • id - random long returned for log method call
  • parent_id - id negative for root entries and is the id of source of the entry (IDE client, server, etc.)
  • timestamp - long with ms since epoch
  • user - long user id (artifact id of a user artifact)
  • type_id - a fine-grained application defined type (might use ranges) defined as tokens with a long and name (which is not in db)
  • log entries where duration does not apply have a duration of -1
  • log entries where duration applies start with a duration of -2 and are updated only when the associated job ends
  • Status:
 0-99    percent complete
 200 OK  completed normally
 4xx     client error (as defined for HTTP Status Code Definitions)
 500     server error (as defined for HTTP Status Code Definitions)
  • server uses a queue to collect log entries for a short time (configurable) and then insert them in batch. This means that any update to a log entry that occurs in less than this configured time will not require a database update (i.e. writing the duration of a short operation).
 Optimize JDBC Performance

Exception Handeling


  • avoid unnecessary wrapping of exceptions


Checked exceptions I love you, but you have to go Why should you use Unchecked exceptions over Checked exceptions Clean Code by Example: Checked versus unchecked exceptions

  • Use application specific exceptions that extend RuntimeException - application specific allows for setting exception breakpoints in the debugger
  • Do not declare any run-time exceptions in any method signatures

Back to the top