Github user franz1981 commented on the issue:
https://github.com/apache/activemq-artemis/pull/1650
@clebertsuconic Argh!! Sorry about the wrong PR: I will repush it!
Just a couple of observations:
to be 100% fair, the lock solution is not always that slow (like the in
memory case is showing) when I/O (networking) is involved: in that case is just
~15% slower (eg that's on my notebook that has a single socket, with servers
would be greater due to the context switch & kernel space journey for each
task).
> The advantage of the lock here is reentrancy.
:100: true! But I've avoided to implement it with a reentrant solution due
to the advices received on a past PR: probably it is an antipattern (I
suppose). If I'm wrong on that I can write a reentrant version too, but it will
change further the logic (it is already complex!).
The solution with the lock is much simpler hence I understand 100% if the
lock free version wouldn't be accepted and if you'll find any error on the
logic of what I've done we can fix it together (before any merge) :)
Probably it could be made simpler too
---
