[
https://issues.apache.org/jira/browse/SLING-13212?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Roy Teeuwen updated SLING-13212:
--------------------------------
Description:
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
was:
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.
This change is additive: the existing LogStore.getRecent(...) API is untouched,
and consumers that don't register a LogEntryListener see no behavioural
difference.
> 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
>
> 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)
