Aias00 opened a new issue, #7839:
URL: https://github.com/apache/shenyu/issues/7839

   ## Goal
   
   Evaluate reducing repeated full-group cache regeneration during bursts of 
independent, committed configuration events in HTTP long-polling deployments. 
Preserve bounded notification latency, transaction visibility and event 
semantics.
   
   ## Current remaining work
   
   
[AbstractDataChangedListener.onRuleChanged():220–227](https://github.com/apache/shenyu/blob/04f7c2e8b7d282f14510157a9ab0bfaab538ecac/shenyu-admin/src/main/java/org/apache/shenyu/admin/listener/AbstractDataChangedListener.java#L220-L227)
 groups one event by namespace and calls updateRuleCache. 
[updateRuleCache():392–393](https://github.com/apache/shenyu/blob/04f7c2e8b7d282f14510157a9ab0bfaab538ecac/shenyu-admin/src/main/java/org/apache/shenyu/admin/listener/AbstractDataChangedListener.java#L385-L394)
 reloads all rules for that namespace. 
[updateCache():340–351](https://github.com/apache/shenyu/blob/04f7c2e8b7d282f14510157a9ab0bfaab538ecac/shenyu-admin/src/main/java/org/apache/shenyu/admin/listener/AbstractDataChangedListener.java#L340-L351)
 serializes/hashes the complete list before it can skip an unchanged MD5. 
Selector and other group cache paths use the same pattern.
   
   An already-batched event performs one rebuild per namespace; that behavior 
is correct and should remain. A burst of separate configuration requests/events 
can still perform repeated complete reloads even when only the final published 
cache state matters to long-poll readers.
   
   ## Important distinction from fixed work
   
   #6576 was closed by PR #7181, which batches selector import data-sync 
events. Do not report a current 1,000-row selector import as producing 1,000 
data-sync rebuilds without evidence: that path was fixed. This follow-up 
specifically evaluates multiple independent committed events, such as rapid 
edits by API clients, rather than undoing or duplicating import batching.
   
   #6569 addressed the older global-lock/namespace refresh problem; this task 
is not a blanket increase of scheduler threads or reintroduction of global 
refresh. It applies to the HTTP/cache-listener path, not a claim that the 
WebSocket gateway itself queries the database per business request.
   
   ## Scope and acceptance
   
   - [ ] Benchmark sustained and burst independent updates for one 
group/namespace, multiple groups and multiple namespaces; record DB queries, 
full serialization/hash counts, allocations, convergence and request p99.
   - [ ] Evaluate a bounded dirty-key/rebuild generation mechanism or a 
measured short coalescing window at the cache/notification layer. Define the 
maximum added notification latency and overload behavior.
   - [ ] Keep every business/audit/domain event and required plugin callback. 
Coalescing cache rebuild work must not blindly drop DELETE/UPDATE ordering or 
after-commit boundaries.
   - [ ] Handle writes arriving during a rebuild: a generation/dirty state must 
ensure that the newest committed configuration is eventually published. Do not 
lose wakeups by clearing a pending marker too early.
   - [ ] Preserve MD5/version comparison, long-poll wakeups, authoritative 
empty groups, rollback behavior and isolation between namespaces.
   - [ ] Retain #7181's import batching and its tests; add concurrent 
independent-event and rollback tests. Keep current behavior where coalescing is 
disabled or not beneficial.
   - [ ] Retain only measured benefit under an explicit convergence budget; 
publish commands and results.
   
   ## Related work
   
   #7645 batches application of a received gateway snapshot. This task is 
producer-side HTTP cache rebuild work. #7832 trims transport fields, not 
database read/rebuild frequency.
   
   ## Baseline and validation boundary
   
   Reviewed Apache ShenYu `2.7.2-SNAPSHOT`, master 
`04f7c2e8b7d282f14510157a9ab0bfaab538ecac`. Source inspection confirms the 
processing described here; no before/after load benchmark has been run and no 
fixed performance gain is claimed. Use #7650's reproducible benchmark contract: 
warm JVM, identical configuration/resources, controlled payload shapes, 
repeated runs, CPU/allocation/GC, synchronization convergence and 
business-request p99 during sync. No new production dependency is required for 
this proposal.
   


-- 
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