- Notifications
You must be signed in to change notification settings - Fork 619
Make ReactiveDefaultBookmarkManager return a copy of bookmarks #2769
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Make ReactiveDefaultBookmarkManager return a copy of bookmarks #2769
Conversation
285c18b to 9cc1210 Compare 69c7863 to 6cccde7 Compare This update makes sure that the `ReactiveDefaultBookmarkManager` returns an unmodifiable copy of its current bookmarks instead of returning a view of the bookmarks.
6cccde7 to 8720b85 Compare There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
OOps.
Thank you.
This update makes sure that the `ReactiveDefaultBookmarkManager` returns an unmodifiable copy of its current bookmarks instead of returning a view of the bookmarks.
| At some point the code that @injectives suggested for
got replaced with
which although looks a lot prettier it still doesn't prevent Stack trace: |
| That's indeed true. Excellent catch. |
The separate reactive bookmark manager was introduced because Project Reactor and Blockhound have issues with the `ReentrantReadWriteLock` approach we have taken in the imperative approach. The first approach was using a synchronized set, but as it was correctly noted by @seabamirum on #2769 this is not enough on the reading path: > It is imperative that the user manually synchronize on the returned set when iterating over it: (From the JavaDoc of `Collections.synchronizedSet`. Using `ConcurrentHashMap.newKeySet` would solve that issue, but it would require a check for `null` values in the `usedBookmarks` argument for `updateBookmarks` AND it would also not solve the fact that removing the used bookmarks and adding the new ones is an atomic operation (such as it originally was in the imperative world). So therefor it is just easier to use a standard set and synchronize over it.
The separate reactive bookmark manager was introduced because Project Reactor and Blockhound have issues with the `ReentrantReadWriteLock` approach we have taken in the imperative approach. The first approach was using a synchronized set, but as it was correctly noted by @seabamirum on #2769 this is not enough on the reading path: > It is imperative that the user manually synchronize on the returned set when iterating over it: (From the JavaDoc of `Collections.synchronizedSet`. Using `ConcurrentHashMap.newKeySet` would solve that issue, but it would require a check for `null` values in the `usedBookmarks` argument for `updateBookmarks` AND it would also not solve the fact that removing the used bookmarks and adding the new ones is an atomic operation (such as it originally was in the imperative world). So therefor it is just easier to use a standard set and synchronize over it.
The separate reactive bookmark manager was introduced because Project Reactor and Blockhound have issues with the `ReentrantReadWriteLock` approach we have taken in the imperative approach. The first approach was using a synchronized set, but as it was correctly noted by @seabamirum on #2769 this is not enough on the reading path: > It is imperative that the user manually synchronize on the returned set when iterating over it: (From the JavaDoc of `Collections.synchronizedSet`. Using `ConcurrentHashMap.newKeySet` would solve that issue, but it would require a check for `null` values in the `usedBookmarks` argument for `updateBookmarks` AND it would also not solve the fact that removing the used bookmarks and adding the new ones is an atomic operation (such as it originally was in the imperative world). So therefor it is just easier to use a standard set and synchronize over it.
This update makes sure that the
ReactiveDefaultBookmarkManagerreturns an unmodifiable copy of its current bookmarks instead of returning a view of the bookmarks.