konlue opened a new pull request, #7663: URL: https://github.com/apache/shenyu/pull/7663
Fixes #7643 ## Modifications - `AbstractShenyuPlugin`: the two unconditional INFO lines in `defaultMatchSelector` and `defaultMatchRule` are removed; match-success diagnostics stay in `printLog`, which sits behind the explicit `logged`/`loged` switch and carries the selector or rule name. - `ShenyuWebsocketClient#handleResult`: the full payload moves to DEBUG; INFO carries only groupType / eventType / namespaceId / payload size in UTF-8 bytes, logged after parsing succeeds. Two commits: the change itself, and a self-review follow-up (byte-accurate payload size instead of `String.length()`, plus test-helper cleanup). ## Why the two match lines are removed rather than demoted `printLog` already sits behind the explicit setting — it checks `selectorData.getLogged()` and `ruleData.getLoged()`, and it carries the selector or rule name. `defaultMatchSelector` and `defaultMatchRule` logged the same event a second time with no switch at all, so a user who had not enabled logging still received one INFO line per matched request, while the same request arriving through the cache path stayed quiet. Both lines were added by the same refactor that introduced `printLog` (#4578), and `printLog` runs on the result of both methods unconditionally afterwards, so the two lines described an event that was already covered. Demoting them to DEBUG would have left two DEBUG lines for a single match — the duplication the scope asks to avoid — so they are removed. The surviving INFO line is the one that names the selector or rule, which is the more useful of the two. This also matches the "or the explicit matching-log setting" half of the scope: the diagnostics now live in exactly one place and that place is gated. ## Why handleResult moves its metadata line after parsing The payload used to be logged before `GsonUtils.fromJson`, so a frame that turned out to be malformed was written out in full before the catch discarded it. `groupType` is needed for the new INFO line and is only available once parsing has succeeded, so the line is emitted after the parse. Consequence: a malformed frame produces only its WARN, which is the intended outcome — an unparseable frame should not reach INFO at all. The size is counted as UTF-8 bytes rather than `String.length()`, which would count UTF-16 chars and understate non-ASCII configuration content. ## Volume The two removed lines cost 51 and 44 bytes of message text per match (95 bytes before logback's own line prefix) for a default plugin name. That figure is derived from the message constants, not measured. What I cannot give you is the measured side of the comparison — a before/after rate, an allocation rate, a CPU share or a p99. The repo has no JMH infrastructure and I don't have a bare-metal Linux box, so a number I produced here would reflect one laptop rather than the workload you care about. If that measurement is the gate for this one, I understand it, and the change is small enough to re-measure wherever the baseline infrastructure lands. ## Tests `AbstractShenyuPluginTest` gains five cases: - `defaultStrategySelectorMatchShouldNotLogWhenLoggingDisabled` / `...RuleMatch...` — no selector or rule line reaches INFO when the flag is false. - `defaultStrategySelectorMatchShouldLogExactlyOnceWhenLoggingEnabled` / `...Rule...` — exactly one line reaches INFO when the flag is true, and it is the name-carrying one. These are what pin the de-duplication. - `defaultStrategyMatchLogsShouldNotChangeRoutingResults` — `doExecute` still receives the same selector and rule. Removing the two `getLogged()` / `getLoged()` guards makes the disabled cases fail, so the tests do pin the behaviour rather than merely passing alongside it. The cases use a small `LogCapture` helper (a logback `ListAppender` wrapper that attaches to one logger and detaches on close), so no logging state leaks between tests. `logback-classic` is added with `test` scope, matching `shenyu-plugin-wasm-api` and `shenyu-sync-data-http` — this module had only `slf4j-api` on the test classpath, so there was no logging implementation to assert against. `ShenyuWebsocketClientTest` already exercises the `handleResult` paths (malformed frame, unknown group type, unknown event type) and passes unchanged, which is the evidence that the behaviour is the same and only the level and message content moved. ## Scope Log output only. No new configuration flag, no change to matching or routing logic, and no `getLoged()` spelling change — that is #7589's scope, keeping this PR clean. ## Verifying this change ```text shenyu-plugin-base: Tests run: 239, Failures: 0, Errors: 0, Skipped: 0 shenyu-sync-data-websocket: Tests run: 120, Failures: 0, Errors: 0, Skipped: 0 maven-checkstyle-plugin: 0 Checkstyle violations Rat check: Unapproved: 0 ``` (after the self-review follow-up commit: AbstractShenyuPluginTest 13/13 and ShenyuWebsocketClientTest 34/34 re-run green) -- 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]
