A few thoughts here: 1) Run-time configuration (or even compile-time inclusion/exclusion?) that allows you to enable/disable the “raw” mode in both Cassandra and Sidecar would be a reasonable middle-ground here. I’m not crazy about exposing it by default though, so I’d a minimum have it default to disabled. 2) Different APIs exposed via `nodetool` (where you generally already have node-local access) and Sidecar, with different levels of complexity. 3) The more input we get from “users who actually use the profiler today,” the better the “safe” API can be, so maybe you won’t (generally) need to deploy with the raw endpoint enabled. To Jon specifically, do you have in easy-cass-lab or anywhere else examples of how you’re using the profiler today that we could use to help guide the API design? I know you’ve got plenty to do so if there’s something we can dig into without requiring you to do it yourself I’d be happy to try to dig out requirements from there.
Doug > On Jun 22, 2025, at 8:10 PM, Josh McKenzie <jmcken...@apache.org> wrote: > >> If sidecar wishes to expose exec and take the fact that this API could break >> on it, I am +0 to that. I mostly am trying to highlight the risk > Trying to disambiguate here. > > "This API": we referring to our friendly simple exposed subset? Or are we > referring to "you passed --raw and whatever is parsing that could drift." > > The former we have control over. The latter not so much. > > I'm +0 to taking on (and breaking) the latter; we either allow power users to > pass arg strings directly and stay frozen if the API in the profiler changes, > or we just rev the profile dep as needed and let power users eat the > re-architecting costs. In my head: they're power users. They can update their > profiler... profiles... locally; not so big a burden. > > On Sun, Jun 22, 2025, at 3:40 PM, David Capwell wrote: >>> it sounds like you’re saying users who actually use the profiler today are >>> SOL and need to roll their own solution. >> >> No, I am saying it’s good to have sidecar expose this and expose common >> patterns that people actually use. >> >> If sidecar wishes to expose exec and take the fact that this API could break >> on it, I am +0 to that. I mostly am trying to highlight the risk >> >>> On Jun 20, 2025, at 2:54 PM, Jon Haddad <j...@rustyrazorblade.com> wrote: >>> >>> Well, the discussion is about sidecar doing it. it sounds like you’re >>> saying users who actually use the profiler today are SOL and need to roll >>> their own solution. >>> >>> >>> On Fri, Jun 20, 2025 at 10:24 AM David Capwell <dcapw...@apple.com >>> <mailto:dcapw...@apple.com>> wrote: >>>> However, for folks like me that know the command line options and >>>> regularly do things that you might not have planned out, I'd appreciate an >>>> escape hatch where I can pass my raw commands >>> >>> For more “advanced” users, normal profile.sh would still be able to >>> profile, just requires more steps. >>> >>>> I think supporting both an abstraction-layer bound "simple mode" and a >>>> "--raw for experts" is the way to go. >>> >>> How do we say “this API has 0 compatibility for C* and can break w/e”? >>> >>>> On Jun 20, 2025, at 5:22 AM, Josh McKenzie <jmcken...@apache.org >>>> <mailto:jmcken...@apache.org>> wrote: >>>> >>>> I think supporting both an abstraction-layer bound "simple mode" and a >>>> "--raw for experts" is the way to go. >>>> >>>> On Thu, Jun 19, 2025, at 1:23 PM, Jon Haddad wrote: >>>>> I understand the motivation to decouple the command line configuration >>>>> from what we expose to end users, and to an extent, agree with the >>>>> reasoning. However, for folks like me that know the command line options >>>>> and regularly do things that you might not have planned out, I'd >>>>> appreciate an escape hatch where I can pass my raw commands. Whatever >>>>> you end up implementing, there's almost certainly commands that >>>>> experienced async-profiler folks will want to use that weren't planned >>>>> for. >>>>> >>>>> I am also not particularly interested in learning another syntax only to >>>>> have it transformed into the thing I want to use. I expect that would be >>>>> a fairly simple flag (nodetool profile --raw xyz) that would skip the >>>>> parse logic, so hopefully it's not too much trouble to add. Reverse >>>>> engineering the async profiler syntax into the thing we decide to use is, >>>>> at least for me, will be a source of frustration. >>>>> >>>>> Thanks, >>>>> Jon >>>>> >>>>> >>>>> >>>>> On Wed, Jun 18, 2025 at 4:01 PM Abe Ratnofsky <a...@aber.io >>>>> <mailto:a...@aber.io>> wrote: >>>>> Another vote in favor of including async-profiler as a library in C*. The >>>>> new heatmap format in async-profiler 4.0[1] is excellent and makes >>>>> long-running profiles miles more useful than a plain flamegraph, but it >>>>> requires a post-processing step after a JFR is collected, which would >>>>> require a dependency on jfr-converter.jar[2]. Exposing the JFR files >>>>> directly would be reasonable but slightly less useful, and the >>>>> post-processed heatmap HTML files are much smaller and self-contained. A >>>>> recent example on my machine shows HTML at 1/20th the size of the raw JFR >>>>> dump, which is meaningful especially for uploading to Jira. >>>>> >>>>> Note that JDK25 will have experimental support for better CPU >>>>> profiling[3], but async-profiler is still more mature and featureful, >>>>> especially for other profiling types (wall, alloc). >>>>> >>>>> [1]: >>>>> https://github.com/async-profiler/async-profiler/blob/master/docs/Heatmap.md >>>>> [2]: >>>>> https://github.com/async-profiler/async-profiler?tab=readme-ov-file#stable-release-40 >>>>> [3]: >>>>> https://mostlynerdless.de/blog/2025/06/11/java-25s-new-cpu-time-profiler-1/ >>>> >
