Aias00 opened a new issue, #7751: URL: https://github.com/apache/shenyu/issues/7751
### Current behavior `ShenyuLoaderService.loaderPlugins()` installs plugin instances from the candidate classloader and passes the new data-handler instances to `CommonPluginDataSubscriber`. However, `putExtendPluginDataHandler()` uses `computeIfAbsent` keyed by `pluginNamed()`. On a same-name replacement, the new handler is discarded and the subscriber retains the old one. ### Locations / supported flow - [CommonPluginDataSubscriber.java:99–109](https://github.com/apache/shenyu/blob/66d7d954ca37d651a5ad916f988a8081157a7ab4/shenyu-plugin/shenyu-plugin-base/src/main/java/org/apache/shenyu/plugin/base/cache/CommonPluginDataSubscriber.java#L99) - [ShenyuLoaderService.java:107–114](https://github.com/apache/shenyu/blob/66d7d954ca37d651a5ad916f988a8081157a7ab4/shenyu-web/src/main/java/org/apache/shenyu/web/loader/ShenyuLoaderService.java#L107) - `ShenyuPluginClassLoaderHolder.replacePluginClassLoader()` activates the new results and then closes the previous loader. - Subsequent plugin/selector/rule updates dispatch through the subscriber's existing `handlerMap`. This report concerns a replacement JAR successfully supplied through the upload/replacement path; it does not depend on the ext-directory scanner detecting an overwritten file. ### Reproduction / validation A standalone Java probe compiled the current subscriber and its current interface. It registered two distinct handler instances with the same plugin name in sequence, then invoked the actual public `onSubscribe(PluginData)` dispatch: ```text AFTER_REREGISTER v1Callbacks=1 v2Callbacks=0 ``` The second handler receives no configuration callback. An independent reviewer traced the loader replacement path and verified no corresponding map replacement occurs. This is a subscriber-layer executable reproduction plus loader source tracing; a full packaged-JAR/classloader deployment was not run. ### Impact / suggested fix New plugin execution code can run while configuration callbacks still invoke the old generation, leading to stale caches/behavior and retention of old handler/classloader references. Replace dynamically owned handlers as part of a coordinated generation handoff, while protecting built-in handler ownership and defining cleanup/removal behavior for old generations. Ensure subsequent config callbacks target the active plugin generation. ### Related existing work #6725 concerns detecting an ext JAR changed at the same path and is explicitly excluded here. #6630 concerns removal from the plugin execution chain; #6730 concerns bean-name collisions during close/reload; #5508 is a broad old JAR-version reload report. This issue identifies the separate, deterministic subscriber map behavior after candidate handler instances have already been supplied. ### Reviewed revision Apache ShenYu 2.7.2-SNAPSHOT, `master@66d7d954ca37d651a5ad916f988a8081157a7ab4`. P2 / Medium, high confidence. Unit-test and CI issue categories excluded. -- 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]
