> If disabled, which is default, I def won’t block on this, I just want us to think about these possible problems before we touch a public API; ill leave it to author(s)/reviewer(s).
One thing that has been brought up in a different context is if we can make breaking changes to public facing APIs if the thing is disabled by default (debug tables is the example); I personally don’t have clarity here for the project so hard to say. TL;DR I am +0 > On Dec 11, 2025, at 3:30 AM, Štefan Miklošovič <[email protected]> wrote: > > Oh wow! Thanks Dmitry for all these references. I think that the fact > Corretto includes that into JDK is the testament of the quality. > > David, I hope this answers your concerns pretty much? > > On Thu, Dec 11, 2025 at 12:27 PM Dmitry Konstantinov <[email protected]> > wrote: >> >> + 1 from my side >> >> 1) it is well known mature profiling tool, there are other cases when Apache >> projects embedded it, for example: >> - https://issues.apache.org/jira/browse/HADOOP-18055 >> - https://issues.apache.org/jira/browse/HBASE-29045 >> - https://issues.apache.org/jira/browse/FLINK-33325 >> 2) Apache-2.0 license >> 3) the dependency has a small size (less than 1Mb) and does not have >> transitive dependencies to other 3rd parties >> 4) the main contributors are now in Amazon, it is even included into >> Corretto JDK now >> (https://aws.amazon.com/about-aws/whats-new/2025/10/amazon-corretto-october-2025-quarterly-updates/ >> ) >> 5) the logic is disabled by default, so no impact if you do not use it. >> >> >> On Wed, 10 Dec 2025 at 18:08, Štefan Miklošovič <[email protected]> >> wrote: >>> >>> This capability is disabled by default, it is driven by a system >>> property you have to set to true in order to be able to get an >>> instance of AsyncProfiler which does the actual profiling. If >>> disabled, which is default, then any calls via nodetool which needs >>> AsyncProfiler (start, stop, status) would return a message that >>> profiling is not enabled. >>> >>> Not sure if this answers your concerns but without knowingly turning >>> it on nothing happens. >>> >>> On Wed, Dec 10, 2025 at 6:28 PM David Capwell <[email protected]> wrote: >>>> >>>> I have no issues adding it. I think my only real comment would be the >>>> same as with manager; w/e we expose to the public api (in this case >>>> Nodetool) we have to support, so if a 3rd party lib breaks compatibility >>>> that puts us in a bind if we didn’t think about that up front. >>>> >>>> Having async-profiler exposed makes it easier to profile is a good thing. >>>> Manager has (or is in the process of adding) API auth so we can lock down >>>> async-profiler to those “allowed” but do we have similar in Nodetool? We >>>> had an issue in the past that async-profiler would trigger a JVM crash >>>> (JVM bug), so we had to limit calls to it until it was fixed. >>>> >>>>> On Dec 10, 2025, at 9:00 AM, Štefan Miklošovič <[email protected]> >>>>> wrote: >>>>> >>>>> Worth to mention that we were also contemplating about the inclusion >>>>> of jfr-convert so a user can also convert raw JFR files to e.g. HTML >>>>> with heatmaps but we evaluated that it is not necessary. Sure, it >>>>> would be comfortable, but ultimately not needed. Conversion of such a >>>>> file via nodetool, on server side, is just not a good idea, it is not >>>>> a job of a server to convert anything. >>>>> >>>>> In majority of cases, people using the profiler just want to get a >>>>> HTML with cpu / allocation profile, it can even gather JFR files as >>>>> such and fetch it is, it is just that the conversion as such can >>>>> happen on client's side instead. >>>>> >>>>> I am +1 for introducing the core async profiler library only. >>>>> >>>>> On Wed, Dec 10, 2025 at 5:46 PM Bernardo Botella >>>>> <[email protected]> wrote: >>>>>> >>>>>> Hi everyone! >>>>>> >>>>>> I’d like to propose adding the async-profiler library to the Cassandra >>>>>> project. This will enable us to add a new nodetool command to do >>>>>> profiling tasks on the process running Cassandra. This information can >>>>>> be useful to debug a wide range of potential issues and performance >>>>>> optimizations. CASSANDRA-20854 captures the effort and the details of >>>>>> the proposal, and this PR proposes its implementation. >>>>>> >>>>>> I want to note that this feature was already discussed in this thread, >>>>>> and this one only want to make sure that no one has any concerns about >>>>>> adding the library as a dependency. >>>>>> >>>>>> What is async-profiler? >>>>>> async-profiler is a low overhead sampling profiler for Java that does >>>>>> not suffer from the Safepoint bias problem. It features HotSpot-specific >>>>>> API to collect stack traces and to track memory allocations. The >>>>>> profiler works with OpenJDK and other Java runtimes based on the HotSpot >>>>>> JVM. >>>>>> >>>>>> Unlike traditional Java profilers, async-profiler monitors non-Java >>>>>> threads (e.g., GC and JIT compiler threads) and shows native and kernel >>>>>> frames in stack traces. >>>>>> >>>>>> What can be profiled: >>>>>> >>>>>> CPU time >>>>>> Allocations in Java Heap >>>>>> Native memory allocations and leaks >>>>>> Contended locks >>>>>> Hardware and software performance counters like cache misses, page >>>>>> faults, context switches >>>>>> and more. >>>>>> >>>>>> >>>>>> We propose to add async-profiler 4.2 as a dependency to Cassandra. >>>>>> >>>>>> Any concerns? >>>>>> Bernardo >>>> >> >> >> >> -- >> Dmitry Konstantinov
