lizhimins commented on issue #4048:
URL:
https://github.com/apache/rocketmq-dashboard/issues/4048#issuecomment-5602328736
Resolved by #4049 (merged into `rocketmq-studio` as c6b546a7).
The diagnosis in this issue was exact: the SpEL key `'page:' + #search + ':'
+ #type + ':' + #page + ':' + #pageSize` renders a null `String` as the literal
text `null`, so `(null, null, 1, 20)` and `("null", null, 1, 20)` hashed to the
same `data-sources` entry and the second caller was served the first caller's
page. The fix drops the explicit key so Spring's `SimpleKeyGenerator` is used;
`SimpleKey` keeps the arguments and compares with `Arrays.deepEquals`, so null
and the four-character string `null` are distinct keys.
`SettingsServiceCachingTest.pagedInventoryShouldDistinguishNullFromLiteralNullSearchTest`
pins it through a real caching proxy (`@ContextConfiguration` over a nested
`@EnableCaching` config, `SettingsService` autowired rather than constructed),
asserting both that the two calls return their own objects and that the
repository is hit once for each argument shape. We confirmed the test is
sensitive to the fix by restoring the old SpEL key and watching it fail.
The no-argument `listDataSources()` shares the cache name but resolves to
`SimpleKey.EMPTY`, which cannot collide with a four-element `SimpleKey`, and
the three `@CacheEvict(allEntries = true)` sites do not depend on the key, so
invalidation is unchanged.
GitHub did not auto-close this from the `Fixes` reference because the merge
target is `rocketmq-studio` rather than the repository default branch.
--
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]
