dmsolr opened a new pull request, #7856:
URL: https://github.com/apache/shenyu/pull/7856

   ## Which issue
   
   Refs #7837 — [Task][Performance] Avoid full-payload redaction and 
serialization for Admin WebSocket logs.
   
   ## What this PR does
   
   This delivers the deterministic, benchmark-independent part of #7837.
   
   `WebsocketCollector.send(namespaceId, message, type)` passed 
`maskSensitive(message)` as an
   INFO argument. Java evaluates arguments before the logger checks its level, 
so on **every**
   config push the whole message was parsed into maps/lists, recursively 
traversed and
   re-serialized into a second complete JSON string — even when INFO was 
disabled, and before
   the send path discovered whether any matching sessions existed.
   
   Changes (all in `WebsocketCollector.send(namespaceId, ...)`):
   
   - **Level-guard the diagnostic.** The INFO branch is wrapped in 
`LOG.isInfoEnabled()`.
   - **Log bounded metadata, not the payload.** INFO now logs `namespaceId`, 
`eventType` and
     `size (chars)` instead of the entire message. The 
`group`/`eventType`/`item count` are
     already logged by the publisher 
(`WebsocketDataChangedListener.sendByNamespace`), so this
     reuses metadata available to the publisher instead of reparsing a large 
JSON to recover it.
   - **Keep the full payload as an opt-in DEBUG diagnostic**, still redacted 
via `maskSensitive`
     and now lazy/level-guarded (`if (LOG.isDebugEnabled())`), so the 
unredacted message is
     never logged.
   - Validation (blank message/namespace) and delivery are unchanged and run 
regardless of the
     log level.
   
   ## Acceptance mapping
   
   - *Log event metadata rather than an entire payload; reuse publisher 
metadata* — INFO now
     carries `namespaceId`/`eventType`/`size`; `group`/`count` remain on the 
publisher's log.
   - *Opt-in detailed diagnostic stays redacted + lazy/level-guarded* — DEBUG 
path uses
     `maskSensitive` behind `isDebugEnabled()`.
   - *Disabled INFO/detailed diagnostics do not invoke full-payload 
parsing/redaction/serialization* —
     `maskSensitive` is now reachable only inside the DEBUG guard; the INFO 
path allocates nothing
     beyond an `int` length. Delivery/validation are preserved when logs are 
disabled.
   - *Exercise ordinary sends / empty data / absent sessions / malformed input; 
keep sequence and
     send-failure handling unchanged* — the existing `WebsocketCollectorTest`,
     `WebsocketDataChangedListenerTest` and `WebsocketDataReconcilerTest` cover 
these and stay
     green; `maskSensitive` redaction remains covered by 
`testNestedApiKeysAreRedacted`.
   
   ## Test
   
   Added `testSendWithNamespaceIdLogsBoundedMetadataNotThePayload`: it attaches 
a Logback
   `ListAppender` to the **root** logger (so it captures the collector's events 
whether the
   collector's static `LOG` is the real logger or the `@BeforeAll` spy) and 
asserts an ordinary
   send emits exactly one bounded INFO diagnostic carrying 
`namespace`/`eventType`/`size` and
   **none** of the payload shape (`groupType`), the secret, or the redaction 
marker (`******`).
   
   The test was verified green in both surefire fork orderings (run alone, and 
run after the
   other websocket listener tests).
   
   ## Benchmark boundary
   
   Per the issue's validation boundary, no before/after load benchmark has been 
run and no fixed
   performance gain is claimed. The caller-thread CPU/allocation, log 
bytes/sec, queue pressure and
   sync/business p99 measurements at 1k/10k+ payloads are left to #7650's 
reproducible benchmark
   contract. This PR is the deterministic, source-grounded reduction of 
producer-side work.
   
   ## Type of change
   
   Performance (observability path), no functional/delivery behavior change.
   


-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: [email protected]

For queries about this service, please contact Infrastructure at:
[email protected]

Reply via email to