P2
The BotTaskAggregationHandler saves all log records in a list per thread and publishes them when a specific marker is detected in a record. This marker signals the end of a WorkItem run. If a large amount of log messages are generated by a single WorkItem, this can result in a very large amount of log messages being saved. We currently have a case where 18 million+ have been observed when processing the webrevs for https://github.com/openjdk/mobile/pull/16 in MailingListBridgeBot.
The irony here is that the only subclass of this abstract handler, the BotSlackHandler, throws away all log records that are lower level than what it's supposed to log, so we are saving all of these, only to log those of level SEVERE in the end. In the past, this class was also used for logging to logstash, and in that case, when we had one SEVERE log record, we actually wanted to log everything that lead up to it.
To fix this now, I think I will make it an option for the BotTaskAggregationHandler if it should save everything or just above the configured level.
The irony here is that the only subclass of this abstract handler, the BotSlackHandler, throws away all log records that are lower level than what it's supposed to log, so we are saving all of these, only to log those of level SEVERE in the end. In the past, this class was also used for logging to logstash, and in that case, when we had one SEVERE log record, we actually wanted to log everything that lead up to it.
To fix this now, I think I will make it an option for the BotTaskAggregationHandler if it should save everything or just above the configured level.
