Notice: This Wiki is now read only and edits are no longer possible. Please see: https://gitlab.eclipse.org/eclipsefdn/helpdesk/-/wikis/Wiki-shutdown-plan for the plan.
OSEE/ReqAndDesign
< OSEE
Logging
Requirements
- 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
Design
id, parent_id, timestamp, user, log_level, type_id, duration, status, details (maybe in JSON format)
- id - random long returned for log method call
- parent_id - id of entry used for grouping this and related entries. Is negative for root entries and is the id of source of the entry client or server random id. Ranges are used to group by client/server kind (IDE client, app server, rest client).
- timestamp - long with ms since epoch
- user - long user id (artifact id of a user artifact)
- log_level - as defined by java.util.logging.Level
- 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
Requirements
- avoid unnecessary wrapping of exceptions
Design
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