lhotari commented on issue #4372: URL: https://github.com/apache/bookkeeper/issues/4372#issuecomment-2117019217
> The ByteBuf was not coming from a read from the BookKeeper client, because the ByteBug is coming from the network (it is the Pulsar producer that is sending a message and the interceptor processes it) > > But maybe it is a ByteBuf recycled ? It's hard to see how it could result in the stacktrace even if there was a recycling bug. `GetBytesCallbackByteBuf` instance is not stored as a reference anywhere and gets passed as a parameter here: https://github.com/apache/bookkeeper/blob/f8eb7a06a683e690e8a70b5bd72927e4df70aa51/bookkeeper-server/src/main/java/org/apache/bookkeeper/util/ByteBufVisitor.java#L138 . Perhaps it's a profiler issue. Please add `-XX:+UnlockDiagnosticVMOptions -XX:+DebugNonSafepoints` to JVM options [to prevent any issues in this area](https://github.com/async-profiler/async-profiler?tab=readme-ov-file#restrictionslimitations): > * When agent is not loaded at JVM startup (by using -agentpath option) it is highly recommended to use `-XX:+UnlockDiagnosticVMOptions -XX:+DebugNonSafepoints` JVM flags. Without those flags the profiler will still work correctly but results might be less accurate. For example, without `-XX:+DebugNonSafepoints` there is a high chance that simple inlined methods will not appear in the profile. When the agent is attached at runtime, `CompiledMethodLoad` JVMTI event enables debug info, but only for methods compiled after attaching. It might also be useful to compare Async Profiler 2.9 and 3.0 results. Just to be sure that the [new stacktrace solution in 3.0](https://github.com/async-profiler/async-profiler/issues/795) isn't causing the problem. -- 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]
