Sam DeHaan

@carlosalberto initially these additions look good, but it may be prudent to wait until the conversations around the long term support for the JMX metrics gatherer are further along (see...

Took a look at the code, and the runnable is scheduled with [`scheduleWithFixedDelay`](https://docs.oracle.com/javase/8/docs/api/java/util/concurrent/ScheduledExecutorService.html#scheduleWithFixedDelay-java.lang.Runnable-long-long-java.util.concurrent.TimeUnit-), which will wait the allotted collection interval _between_ each execution of the groovy script. We could change...

@akats7 that seems reasonable, though this behavior > I was seeing that it would abandon the current run and start the next run before registering all of the callbacks. is...

I believe this issue should be improved in my PR that addresses several other issues by refactoring how callbacks are created & executed: https://github.com/open-telemetry/opentelemetry-java-contrib/pull/949 I've personally seen the heap get...

#949 was merged and should be available in 1.29.0. This resolves the repeated callbacks issue, as well as several others, let us know if this behavior persists once the new...

From what I can recall, and a quick parse of the source, the collector does not support setting `-Xmx` or the other various memory flags from the JMX receiver. In...

#949 was merged and should be available in 1.29.0. Among other issues addressed in that PR there were memory leaks resolved which may affect this behavior. Let us know if...

@sirianni the issue is that the existing code will register a new callback each time metrics are collected, which each attempts to record the metric value collected when that callback...

#949 was merged and should be available in 1.29.0. Let us know if the issue persists after integrating the next release.

This is strange, I recall having worked on this logging configuration from the jmxreceiver, but I have nothing concrete to draw upon. From all I can see it certainly seems...