道君- Tao Jiuming

> I understand you introduce `MessageListenerExecutor` is for the purpose of keep consume messages in ordering, but the point is the API design. > > I had read the implementation...

> I think that we need to find another solution. ReadWriteLock adds a lot more overhead than StampedLock. Yes, but RoaringBitmap is not designed for Concurrency at all, and the...

> I wonder if it would be a viable option to catch exceptions and retry with a read lock if that happens? Then we may catch a lot of exceptions...

I did a less rigorous test: ```java @Test public void test() { long start = System.currentTimeMillis(); CountDownLatch latch = new CountDownLatch(2); ConcurrentRoaringBitSet bitSet = new ConcurrentRoaringBitSet(); new Thread(() -> {...

When we do Readonly operations on StampLock based ConcurrentRoaringBitSet, it does faster than ReadWriteLock(about 5 times faster), but in the case we use `ConcurrentRoaringBitSet` is Read and Write(about 1:1).

> btw. In Pulsar ConcurrentOpenLongPairRangeSet is only used in RangeSetWrapper and the only usage of that is in ManagedCursorImpl for individualDeletedMessages. In many cases, the operations on individualDeletedMessages are already...

> > Please use write lock for `individualDeletedMessages.resetDirtyKeys();` call in `buildIndividualDeletedMessageRanges` method. > > This is actually a real bug in the current implementation and needs to be fixed even...

this issue looks fixed by https://github.com/apache/pulsar/pull/9046, closing

The implementation seems could work, but I'm not sure is it a good idea that maintain `maxReadPosition` in ML layer, since it is a messaging layer isolation policy which is...

it looks the issue fixed by https://github.com/apache/pulsar/pull/14667, closing