Files
Shailesh Padave 396a09a4fd refactor(metrics): make Monitors self-contained; MetricsCollector becomes a registry wiring bean (#1059)
* refactor(metrics): Monitors owns its CompositeMeterRegistry; MetricsCollector wires registries in

Previously Monitors pulled its registry from MetricsCollector, creating an
awkward dependency from conductor-core → conductor-metrics. Now Monitors
owns the CompositeMeterRegistry directly and exposes addMeterRegistry() /
getRegistry(). MetricsCollector (contribs) becomes a thin Spring wiring
component that calls Monitors.addMeterRegistry() on startup.

- Removes conductor-core → conductor-metrics build dependency (cycle-free)
- Adds conductor-metrics → conductor-core build dependency
- Adds getGauge() / getDistributionSummary() aliases for callers using the
  'get' naming convention
- Deprecates MetricsCollector.getMeterRegistry() in favour of
  Monitors.getRegistry()

* Applied spotless

* test(metrics): add MonitorsTest covering registry ownership and meter APIs

Verifies addMeterRegistry(), getRegistry(), counter/timer/gauge identity
caching, getGauge/getDistributionSummary aliases, and tag isolation.

* test(metrics): add Spring integration test verifying MetricsCollector wires registries into Monitors

Boots a minimal Spring context with a SimpleMeterRegistry, confirms that
counters/timers/gauges recorded via Monitors are visible in the
Spring-wired registry after MetricsCollector initialises.

* Applied spotless

* refactor(metrics): retire conductor-metrics module, move classes to core/server

MetricsCollector moves to core alongside Monitors — they are companion classes
(Monitors owns the registry, MetricsCollector wires Spring-managed registries in).
Registry-specific configs (Logging, CloudWatch, AzureMonitor) move to server where
they belong as deployment-level concerns. No Java code imported from the old
contribs.metrics package, so this is a pure relocation with no call-site changes.

Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>

* refactor(metrics): delete retired conductor-metrics module directory

Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>

* fix(metrics): add micrometer-registry-prometheus to server and server-lite

Without this dependency Spring Boot cannot create PrometheusMeterRegistry,
so /actuator/prometheus silently returns 404 even though
conductor.metrics-prometheus.enabled=true is set in all default configs.

Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>

* chore: simplify metrics comment in server build files

Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>

* fix(build): remove stale :conductor-metrics dep from scheduler-core

The scheduler module (merged from main via #1064) still referenced
:conductor-metrics, which this branch retired. Monitors is already
provided by :conductor-core.

---------
2026-05-21 11:03:21 -07:00
..

Redis Configuration Module

Redis connection and configuration layer for Conductor. Provides the JedisCommands abstraction, connection pooling, Spring auto-configuration, and pool monitoring. Supports three deployment topologies: standalone, cluster, and sentinel.

This module is a dependency of redis-persistence (DAOs) and queues. If you only need a Redis connection without the DAO layer, depend on this module directly.

Deployment Modes

Set conductor.db.type to activate a Redis mode:

Value Mode Configuration Class Jedis Client
redis_standalone Single node RedisStandaloneConfiguration JedisPooled
redis_cluster Cluster (sharded) RedisClusterConfiguration JedisCluster
redis_sentinel Sentinel (HA failover) RedisSentinelConfiguration JedisSentineled

Quick Start

Standalone

conductor.db.type=redis_standalone
conductor.redis.hosts=localhost:6379:us-east-1c

Cluster

conductor.db.type=redis_cluster
conductor.redis.hosts=node1:6379:us-east-1a;node2:6379:us-east-1b;node3:6379:us-east-1c

Sentinel

conductor.db.type=redis_sentinel
conductor.redis.hosts=sentinel1:26379:us-east-1a;sentinel2:26379:us-east-1b;sentinel3:26379:us-east-1c
conductor.redis.sentinel-master-name=mymaster

Host Format

The conductor.redis.hosts property uses a semicolon-separated format:

host:port:rack[:password]
  • host - hostname or IP
  • port - Redis port (6379 for data nodes, 26379 for sentinel nodes)
  • rack - availability zone / rack identifier (e.g., us-east-1a)
  • password - (optional) Redis AUTH password

Multiple hosts are separated by ;:

conductor.redis.hosts=host1:6379:rack1:secret;host2:6379:rack2:secret

Configuration Properties

All properties are prefixed with conductor.redis..

Connection

Property Description Default
hosts Host definitions (see format above) required
user Redis ACL username none
ssl Enable TLS false
ignore-ssl Trust all certificates (cluster mode only, for dev/test) false
database Redis database number (0-15, standalone/sentinel only) 0
sentinel-master-name Sentinel master name (sentinel mode only) mymaster

Connection Pool

Property Description Default
max-connections-per-host Maximum total connections in the pool 10
max-idle-connections Maximum idle connections 8
min-idle-connections Minimum idle connections maintained 5
min-evictable-idle-time-millis Time before an idle connection can be evicted 180000
time-between-eviction-runs-millis Interval between eviction runs 60000
test-while-idle Validate idle connections true
fairness Use fair ordering for connection acquisition true
max-timeout-when-exhausted Max wait for a connection when pool is exhausted 800ms

Cluster-Specific

Property Description Default
max-total-retries-duration Maximum total retry duration for cluster operations 10000ms

Architecture

config package

  • RedisConfiguration - Abstract base. Creates the UnifiedJedis bean and runs a pool monitor thread that publishes connection metrics every 10 seconds.
  • RedisStandaloneConfiguration - Creates a JedisPooled instance.
  • RedisClusterConfiguration - Creates a JedisCluster instance. Supports ignore-ssl for trust-all TLS in dev environments.
  • RedisSentinelConfiguration - Creates a JedisSentineled instance. Sentinel nodes reuse the configured auth and SSL settings so existing secured Sentinel deployments continue to work.
  • RedisProperties - Spring Boot @ConfigurationProperties binding for all conductor.redis.* properties.
  • ConfigurationHostSupplier - Parses the hosts string into Host objects.
  • AnyRedisCondition - Spring condition that matches when conductor.db.type is any Redis variant.
  • AnyRedisConnectionCondition - Matches when Redis is used for either conductor.db.type or conductor.queue.type.

jedis package

  • JedisCommands - Interface abstracting Redis operations across all deployment modes.
  • UnifiedJedisCommands - Implementation backed by UnifiedJedis (used by standalone and sentinel modes).
  • JedisClusterCommands - Implementation backed by JedisCluster. Batch operations (mget, mgetBytes, mset) use ClusterPipeline for cross-shard efficiency.
  • JedisStandalone - Legacy implementation backed by JedisPool. Retained for test compatibility.
  • OrkesJedisProxy - Spring-managed proxy over JedisCommands. Adds convenience methods (hgetAll, findAll, setWithExpiry, etc.), scan-based iteration, and metrics instrumentation.

Pool Monitoring

All modes publish Redis connection pool metrics every 10 seconds via a daemon thread:

  • conductor_redis_connection_active - active connections
  • conductor_redis_connection_waiting - threads waiting for a connection
  • conductor_redis_connection_mean_borrow_wait_time - average time to acquire a connection
  • conductor_redis_connection_max_borrow_wait_time - worst-case connection acquisition time

The monitor is automatically shut down on Spring context close.