wy96f commented on a change in pull request #2703: ARTEMIS-2380 Fix delivering
message in the case of consume close
URL: https://github.com/apache/activemq-artemis/pull/2703#discussion_r310975418
##########
File path:
artemis-server/src/main/java/org/apache/activemq/artemis/core/server/impl/QueueImpl.java
##########
@@ -1175,6 +1179,17 @@ public void addConsumer(final Consumer consumer) throws
Exception {
}
+ @Override
+ public void addLingerRef(Consumer consumer, MessageReference lingerRef)
throws Exception {
+ lingerRef.emptyConsumerID();
+ lingerRefMap.put(lingerRef, consumer);
Review comment:
@franz1981
> Beware putting `MessageReference` into a `Map`:
`MessageReferenceImpl::hashCode` relies on `getMessage().hashCode()` and
`CoreMessage::hashCode` will use the native hash code (like
`java.lang.System#identityHashCode`).
> It is known that it would break biased locking optimization on it (see
https://blogs.oracle.com/dave/biased-locking-in-hotspot for more detail): given
that `CoreMessage` heavily relies on `synchronized` operation, I would suggest
to measure the perf impact of it first
Thanks, franz. I'll have a look and measure the perf.
> On that note, need to ensure order is preserved hashmap looses any ordering
Good point. BTW, as i read from JMS spec, session is not thread safe, so
closing consumer and committing session from which consumer is created can't be
from multiple threads, correct? If not thread safe, the issue referred in this
PR should be happening rarely? Just not sure whether it's deserved to fix this
trivial problem by adding some tricky and fragile code.
----------------------------------------------------------------
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.
For queries about this service, please contact Infrastructure at:
[email protected]
With regards,
Apache Git Services
