lhotari commented on pull request #10480: URL: https://github.com/apache/pulsar/pull/10480#issuecomment-832604122
> @lhotari I agree with @merlimat on " If the issue is that we're using an already released buffer, we should fix that instead." Yes I agree on this, I'll try to dig deeper. :) > It could be caused by i.e. an implementation of the ReadEntriesCallback/ReadEntryCallback/whatever other callback that is expected to properly release entry. Good point. I'll track those release calls. > Or, as you mentioned at the issue, it could be [netty/netty#10986](https://github.com/netty/netty/issues/10986) Pulsar might not be impacted in cases where AbstractCASReferenceCounted base class is used. Here's AbstractCASReferenceCounted release logic: https://github.com/apache/pulsar/blob/5e446a67fcacf340d352eeafdce15a78fb971f19/managed-ledger/src/main/java/org/apache/bookkeeper/mledger/util/AbstractCASReferenceCounted.java#L95-L110 > > Other issue is: do we have a repro? No. I assume that it's a rare issue since there's not many reports about it. It could be possible to achieve a repro at some kind of unit/integration test level using [JCStress](https://github.com/openjdk/jcstress), but it's hard to estimate the effort to achieve a repro. > Have we confirmed that upgrade of Netty to a version with fix [netty/netty#10986](https://github.com/netty/netty/issues/10986) doesn't help? No. The bug report is about concurrent calls to `.recycle()`. As mentioned earlier, that is prevented with AbstractCASReferenceCounted in Pulsar in most cases. -- 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]
