[
https://issues.apache.org/jira/browse/QPID-8782?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=18127305#comment-18127305
]
ASF GitHub Bot commented on QPID-8782:
--------------------------------------
usugumo opened a new pull request, #456:
URL: https://github.com/apache/qpid-broker-j/pull/456
**JIRA Issue**
[QPID-8782](https://issues.apache.org/jira/browse/QPID-8782): [Broker-J]
Buffered broker logs can contain incorrect diagnostic context
**PR Description**
Both `StartupAppender `and `RecordEventAppender `now call
`prepareForDeferredProcessing()` before storing events. This captures values at
logging time, preserving them for startup replay, fallback console output, and
memory-log retrieval.
> [Broker-J] Buffered broker logs can contain incorrect diagnostic context
> ------------------------------------------------------------------------
>
> Key: QPID-8782
> URL: https://issues.apache.org/jira/browse/QPID-8782
> Project: Qpid
> Issue Type: Bug
> Components: Broker-J
> Affects Versions: qpid-java-broker-10.1.0, qpid-java-broker-10.1.1
> Reporter: Takahashi Kiyoshi
> Priority: Minor
>
> When investigating broker activity through the memory logger or replayed
> startup logs, some records contain information from the thread reading or
> replaying the logs rather than the thread that originally produced them.
> The following symptoms can occur:
> * Memory log entries show the management thread’s name instead of the worker
> thread that logged the event.
> * Replayed startup logs lose the original MDC values or contain values
> belonging to the replay thread.
> * Parameterized messages containing mutable objects reflect changes made
> after the logging call.
> This makes troubleshooting misleading: events can appear to originate from
> the wrong thread, lose their diagnostic context, or describe a different
> state from the one present when they were logged. Startup diagnostics
> replayed to the failure console can also be affected.
> The problem occurs because buffered events retain lazily evaluated fields
> without resolving them on the originating thread. It may be masked when
> another appender resolves those fields during the original logging call.
> Expected behavior: Buffered records should preserve the thread name, MDC
> values and formatted message from the original logging call, regardless of
> when or where they are subsequently read or replayed.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
