[jira] [Resolved] (SLING-13212) LogEntryListener push API for log event subscribers

["Roy Teeuwen (Jira)" <ji...@apache.org>]

     [ https://issues.apache.org/jira/browse/SLING-13212?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Roy Teeuwen resolved SLING-13212.
---------------------------------
    Fix Version/s: Commons Log 6.1.2
       Resolution: Fixed

> LogEntryListener push API for log event subscribers
> ---------------------------------------------------
>
>                 Key: SLING-13212
>                 URL: https://issues.apache.org/jira/browse/SLING-13212
>             Project: Sling
>          Issue Type: Improvement
>          Components: Commons
>    Affects Versions: Commons Log 6.1.2
>            Reporter: Roy Teeuwen
>            Assignee: Roy Teeuwen
>            Priority: Major
>             Fix For: Commons Log 6.1.2
>
>
> SLING-13188 added an optional in-memory LogStore queryable via LogStore.getRecent(Pattern, LogLevel, int). The query API is well suited to occasional inspection (e.g., a web console panel), but consumers that want to forward log events elsewhere — telemetry pipelines, alerting, audit shipping — are forced into a polling loop with manual de-duplication and a race against the ring buffer's eviction policy.
> Proposal: add a whiteboard-style consumer interface in org.apache.sling.commons.log.logback.store:
> {code:java}
>   @ConsumerType
>   public interface LogEntryListener {
>       void onEntry(LogEntry entry);
>   }
> {code}
> LogStoreRegistrar tracks LogEntryListener services with a ServiceTracker. Each appended entry is fanned out to the currently-registered listeners synchronously on the appender thread, after the entry has been added to the store and outside its internal lock. Listeners registered before the LogStore PID is configured are remembered and attached when the store activates; listeners registered later are attached immediately.
> Listeners are documented to be cheap and non-blocking; if a listener throws, the throwable propagates to the caller (the Logback appender thread) and Logback handles it, which keeps the contract simple and matches how Logback already treats appender exceptions.
> Besides this, I'd also add more structured information about an exception in the LogEntry class, so that we can really create a good telemetry pipeline 



--
This message was sent by Atlassian Jira
(v8.20.10#820010)