Skip to content
This repository has been archived by the owner on Mar 18, 2020. It is now read-only.

Releases: kamon-io/kamon-executors

v2.0.2 - Maintenance Release

29 Oct 14:31
Compare
Choose a tag to compare

Improvements

  • We removed the within configuration section completely from this module, so that it will only have effect on classes when explicitly activated by other modules that add values to the within list (e.g. the JDBC and Twitter Future modules). This works together with a bugfix on Kanela v1.0.2 that makes it possible to work fine. Contributed by @ivantopo via 66e1d26.

v2.0.1 - Maintenance Release

30 Sep 10:48
Compare
Choose a tag to compare

Improvements

  • Depending on the order in which configuration files were loaded, some Callable/Runnable targets for instrumentation wouldn't be taken into account because the default configuration was having an absolute assignment as within = [ ]. This was fixed by @boxsterman via #19.

v2.0.0-RC2 - Build for Scala 2.13

12 Jul 11:19
Compare
Choose a tag to compare
Pre-release

Thanks to @lustefaniak we are now building for Scala 2.13 as well!

v2.0.0-RC1 - Upgrade to Kamon 2.0.0-RC1

18 Jun 11:06
Compare
Choose a tag to compare
Pre-release

Nothing significant changed on this release, just bumped the kamon-core dependency.

v2.0.0-M2 - Support for ExecutionContext and Metrics Renames

03 Jun 18:04
Compare
Choose a tag to compare

Changes since 2.0.0-M1:

Support for ExecutionContext

Starting on this version you can call ExecutorInstrumentation.instrumentExecutionContext and the instrumentation will try to unwrap the underlying ExecutorService and instrument it.

Metric Renames

Up until now we were having a less than ideal usage of metrics and tags in this module. For example, we had a metric called executor.tasks that would count both submitted and completed tasks, which could be differentiated by the state=submitted or state=completed tag, but after thinking about it, these are not different "dimensions" for the same metric but rather different metrics so we separated them. Same with threads and settings metrics. These are the current metrics on this module:

  val MinThreads = Kamon.gauge (
    name = "executor.threads.min",
    description = "Tracks executor minimum number of Threads"
  )

  val MaxThreads = Kamon.gauge (
    name = "executor.threads.max",
    description = "Tracks executor maximum number of Threads"
  )

  val Parallelism = Kamon.gauge (
    name = "executor.parallelism",
    description = "Tracks executor parallelism"
  )

  val ThreadsActive = Kamon.histogram (
    name = "executor.threads.active",
    description = "Samples the number of active threads on the executor service"
  )

  val ThreadsTotal = Kamon.histogram (
    name = "executor.threads.total",
    description = "Samples the total number of threads on the executor service"
  )

  val TasksCompleted = Kamon.counter (
    name = "executor.tasks.completed",
    description = "Tracks the number of tasks that completed execution on the executor service"
  )

  val TasksSubmitted = Kamon.counter (
    name = "executor.tasks.submitted",
    description = "Tracks the number of tasks submitted to the executor service"
  )

  val TimeInQueue = Kamon.timer (
    name = "executor.time-in-queue",
    description = "Tracks the time that tasks spend on the executor service's queue"
  )

  val QueueSize = Kamon.histogram (
    name = "executor.queue-size",
    description = "Samples the number of tasks queued for execution on the executor service"
  )

v2.0.0-M1 - Upgrade to Kamon 2.0

23 May 13:07
Compare
Choose a tag to compare
Pre-release

Moving to Kamon 2.0

This is the first release for the Kamon 2.0 series, targeting 2.0.0-M4 to be specific. The entire implementation has been re-thought in order to fit the improvements in core, including the new organization of metrics/instruments and Context propagation APIs.

Simplified API

The only API surface need to be known is ExecutorsInstrumentation.instrument(...) which will return a new instrumented ExecutorService that tracks metrics and optionally propagates Context when tasks are submitted, without any need for bytecode instrumentation. Beware that when using Futures or similar constructs it is almost necessary to capture the context when a Runnable/Callable instance is created rather than when it is submitted for execution, so most of the time you will most likely want to have bytecode instrumentation instead of this. Something as simple as this should be enough:

val rawExecutor = Executors.newFixedThreadPool(32)
val instrumentedExecutor = ExecutorsInstrumentation.instrument(rawExecutor, "my-executor")

// From this point on, only use instrumentedExecutor.

Built-in Runnable/Callable Instrumentation

This module ships with instrumentation that targets all Runnable/Callable implementations (with a few exceptions), which enables automatic Context propagation for Scalaz Future, Twitter Future, Cats IO and any other case in which a Runnable/Callable is created and some point (capturing the context) and scheduled for execution later on, maybe even from a separate Thread. Notably, this instrumentation is excluding the Runnable instances used by the Scala Future implementation because we got some special code targeting it on the kamon-scala-future module.

Experimental: Capture on Submit

Some of our users have been asking for instrumenting directly on the Executor Service code on the JDK and this version ships with an experimental bytecode instrumentation module that does exactly that: captures the current Context at the moment of submitting the tasks and use it will actually executing it. This module is disabled by default.

v1.0.2 - Remove Unnecessary Dependencies and ContextAwareCallable Rename

09 Aug 14:02
Compare
Choose a tag to compare

Remove Unnecessary Dependencies

Thanks to @Falmarri via #3, this module no longer introduces dependencies on Logback.

Rename of ContinuationAwareCallable

On the name of consistency ContinuationAwareCallable has been renamed to ContextAwareCallable via 86aec8d. The term "Continuation" was a left over from previous efforts in which kamon-core was working closer to the OpenTracing specification, but that is no more, hence the change. Thanks to @dpsoft for the contribution.