lhotari commented on code in PR #23903:
URL: https://github.com/apache/pulsar/pull/23903#discussion_r1932631672
##########
managed-ledger/src/main/java/org/apache/bookkeeper/mledger/util/RangeCache.java:
##########
@@ -106,7 +106,39 @@ K getKey() {
return localKey;
}
+ /**
+ * Get the value associated with the key. Returns null if the key does
not match the key.
+ *
+ * @param key the key to match
+ * @return the value associated with the key, or null if the value has
already been recycled or the key does not
+ * match
+ */
V getValue(K key) {
+ return getValueInternal(key, false);
+ }
+
+ /**
+ * Get the value associated with the Map.Entry's key and value. Exact
instance of the key is required to match.
+ * @param entry the entry which contains the key and {@link
EntryWrapper} value to get the value from
+ * @return the value associated with the key, or null if the value has
already been recycled or the key does not
+ * exactly match the same instance
+ */
+ static <K, V> V getValueMatchingMapEntry(Map.Entry<K, EntryWrapper<K,
V>> entry) {
+ return entry.getValue().getValueInternal(entry.getKey(), true);
+ }
+
+ /**
+ * Get the value associated with the key. Returns null if the key does
not match the key associated with the
+ * value.
+ *
+ * @param key the key to match
+ * @param requireSameKeyInstance when true, the matching will be
restricted to exactly the same instance of the
+ * key as the one stored in the wrapper.
This is used to avoid any races
+ * when retrieving or removing the
entries from the cache when the key and value
+ * instances are available.
+ * @return the value associated with the key, or null if the key does
not match
+ */
+ private V getValueInternal(K key, boolean requireSameKeyInstance) {
Review Comment:
> Object pooling can introduce complexity, such as synchronization overhead,
which can negate performance gains.
@heesung-sn There's no synchronization that is used in this class. Netty's
object pooling solution is very well optimized. I have commented on some of the
tradeoffs in this comment:
https://github.com/apache/pulsar/pull/23903#discussion_r1932599350
> How do we know if this object pooling is required here?
"required" can be understood in many ways. In Pulsar, we do use object
pooling extensively. It's a chosen style in the Pulsar code base. In some
cases, it's not useful. In some cases, it's useful. The only way to be sure
would be to put the effort to benchmark and compare differences in performance.
Removing object pooling isn't the scope of this PR.
With concurrency issues, there's always the doubt whether something is
necessary or not. The changes made in PRs #22789, #22814 and #22818 seem to
have eliminated "use after release" type of bugs that we were facing in Pulsar.
Some of the issues were addressed with bug fixes to Netty in 4.1.111.Final
(mentioned in #22892) and my assumption is that other "use after release"
issues were addressed by the RangeCache changes.
I hope we can continue reviewing this PR and address the bug that this PR
fixes. There are tests that reproduce the issue at different levels.
--
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]
