wy471x opened a new pull request, #7528: URL: https://github.com/apache/shenyu/pull/7528
Fixes #6587 Make sure that: - [X] You have read the [contribution guidelines](https://shenyu.apache.org/community/contributor-guide). - [X] You submit test cases (unit or integration tests) that back your changes. - [X] Your local test passed `./mvnw clean install -Dmaven.javadoc.skip=true`. ## Summary This is the deduplication part of #6587: the websocket sync path has no event dedup, so admin churn is translated 1:1 into gateway CPU. Admin sends the complete payload of a config group on every event of that group, and `WebsocketDataHandler.executor` always handed it to the group handler, which deserializes the whole list and re-caches every entry (`refreshPluginDataAll` + per-row `onSubscribe` for a `REFRESH`/`MYSELF`, per-row `onSubscribe` for an `UPDATE`). When the payload did not actually change — the common case for admin restarts, repeated broadcasts and re-sends — the gateway redid the full deserialize + cache apply for identical data. This PR adds a payload fingerprint per config group: an event whose payload was already applied for that group is skipped instead of being re-applied. Only exact repeats of the payload applied last for that group are skipped; a changed payload, or the same payload under a different event type, is still applied as before. Queueing/batching of the sync path is deliberately left out of this PR to keep it reviewable; the issue's remaining structural work can follow separately. ### Changes: 1. `WebsocketDataHandler.lastAppliedFingerprints` (WebsocketDataHandler.java:47) — new `ConcurrentHashMap<ConfigGroupEnum, String>` holding the fingerprint (`md5(eventType|json)`) of the payload applied last for each group. 2. `WebsocketDataHandler.executor()` (WebsocketDataHandler.java:82) — computes the fingerprint up front, logs and returns when it equals the fingerprint already applied for that group, and records the new fingerprint after `handle` returns. Recording only after a successful `handle` means a payload that failed to apply is never treated as applied. 3. `WebsocketDataHandler.snapshot()` (WebsocketDataHandler.java:109) — drops the fingerprint of the group after an authoritative snapshot, because a snapshot replaces the whole group and a following payload must be applied even when it is byte-identical to the one applied before the snapshot. Fingerprints are per group instance (one `WebsocketDataHandler` per connection) and are also reset when the client is recreated, so a fresh connection starts with an empty dedup state. ### Test Cases: `WebsocketDataHandlerTest` (existing suite, +5 tests): - `testDuplicatedEventIsAppliedOnlyOnce` — the same payload repeated with `REFRESH` reaches the subscriber once (`refreshPluginDataAll` and `onPluginRefresh` verified with `times(1)`). - `testChangedPayloadIsAppliedAgain` — two different payloads for the same group are both applied. - `testSamePayloadWithAnotherEventTypeIsApplied` — an identical payload under a different event type (`UPDATE` after `REFRESH`) still runs. - `testSnapshotInvalidatesDeduplication` — after `snapshot()`, the previously applied payload is applied again. - `testDeduplicationIsPerGroup` — two identical `PLUGIN` events are deduped while the same payload for `SELECTOR` is still applied. ## Verification - `mvn -pl shenyu-sync-data-center/shenyu-sync-data-websocket -am clean install -Dmaven.javadoc.skip=true` — passed (10 reactor modules), checkstyle (validate) and apache-rat included. - Test results: shenyu-sync-data-websocket 120 tests, 0 failures, 0 errors. close #6587 -- 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]
