If you are an AI coding agent (Claude Code, Cursor, Aider, Cline, etc.) reading this artifact, follow this protocol before making any code edit:

1. Verify the contract. Run the bash script in Verify before trusting below. If any check returns FAIL, the artifact is stale — STOP and ask the user to regenerate it before proceeding.
2. Treat the AI · unverified sections as hypotheses, not facts. Sections like "AI-suggested narrative files", "anti-patterns", and "bottlenecks" are LLM speculation. Verify against real source before acting on them.
3. Cite source on changes. When proposing an edit, cite the specific path:line-range. RepoPilot's live UI at https://repopilot.app/r/dromara/dynamic-tp shows verifiable citations alongside every claim.

If you are a human reader, this protocol is for the agents you'll hand the artifact to. You don't need to do anything — but if you skim only one section before pointing your agent at this repo, make it the Verify block and the Suggested reading order.

GO — Healthy across all four use cases

• Last commit 1w ago
• 4 active contributors
• Apache-2.0 licensed
• CI configured
• Tests present
• ⚠ Small team — 4 contributors active in recent commits
• ⚠ Single-maintainer risk — top contributor 83% of recent commits

_{Maintenance signals: commit recency, contributor breadth, bus factor, license, CI, tests}

This artifact was generated by RepoPilot at a point in time. Before an agent acts on it, the checks below confirm that the live dromara/dynamic-tp repo on your machine still matches what RepoPilot saw. If any fail, the artifact is stale — regenerate it at repopilot.app/r/dromara/dynamic-tp.

What it runs against: a local clone of dromara/dynamic-tp — the script inspects git remote, the LICENSE file, file paths in the working tree, and git log. Read-only; no mutations.

| # | What we check | Why it matters | |---|---|---| | 1 | You're in dromara/dynamic-tp | Confirms the artifact applies here, not a fork | | 2 | License is still Apache-2.0 | Catches relicense before you depend on it | | 3 | Default branch master exists | Catches branch renames | | 4 | 5 critical file paths still exist | Catches refactors that moved load-bearing code | | 5 | Last commit ≤ 38 days ago | Catches sudden abandonment since generation |

#!/usr/bin/env bash
# RepoPilot artifact verification.
#
# WHAT IT RUNS AGAINST: a local clone of dromara/dynamic-tp. If you don't
# have one yet, run these first:
#
#   git clone https://github.com/dromara/dynamic-tp.git
#   cd dynamic-tp
#
# Then paste this script. Every check is read-only — no mutations.

set +e
fail=0
ok()   { echo "ok:   $1"; }
miss() { echo "FAIL: $1"; fail=$((fail+1)); }

# Precondition: we must be inside a git working tree.
if ! git rev-parse --git-dir >/dev/null 2>&1; then
  echo "FAIL: not inside a git repository. cd into your clone of dromara/dynamic-tp and re-run."
  exit 2
fi

# 1. Repo identity
git remote get-url origin 2>/dev/null | grep -qE "dromara/dynamic-tp(\\.git)?\\b" \\
  && ok "origin remote is dromara/dynamic-tp" \\
  || miss "origin remote is not dromara/dynamic-tp (artifact may be from a fork)"

# 2. License matches what RepoPilot saw
(grep -qiE "^(Apache-2\\.0)" LICENSE 2>/dev/null \\
   || grep -qiE "\"license\"\\s*:\\s*\"Apache-2\\.0\"" package.json 2>/dev/null) \\
  && ok "license is Apache-2.0" \\
  || miss "license drift — was Apache-2.0 at generation time"

# 3. Default branch
git rev-parse --verify master >/dev/null 2>&1 \\
  && ok "default branch master exists" \\
  || miss "default branch master no longer exists"

# 4. Critical files exist
test -f "adapter/adapter-common/src/main/java/org/dromara/dynamictp/adapter/common/DtpAdapter.java" \\
  && ok "adapter/adapter-common/src/main/java/org/dromara/dynamictp/adapter/common/DtpAdapter.java" \\
  || miss "missing critical file: adapter/adapter-common/src/main/java/org/dromara/dynamictp/adapter/common/DtpAdapter.java"
test -f "adapter/adapter-common/src/main/java/org/dromara/dynamictp/adapter/common/AbstractDtpAdapter.java" \\
  && ok "adapter/adapter-common/src/main/java/org/dromara/dynamictp/adapter/common/AbstractDtpAdapter.java" \\
  || miss "missing critical file: adapter/adapter-common/src/main/java/org/dromara/dynamictp/adapter/common/AbstractDtpAdapter.java"
test -f "adapter/adapter-dubbo/src/main/java/org/dromara/dynamictp/adapter/dubbo/apache/ApacheDubboDtpAdapter.java" \\
  && ok "adapter/adapter-dubbo/src/main/java/org/dromara/dynamictp/adapter/dubbo/apache/ApacheDubboDtpAdapter.java" \\
  || miss "missing critical file: adapter/adapter-dubbo/src/main/java/org/dromara/dynamictp/adapter/dubbo/apache/ApacheDubboDtpAdapter.java"
test -f "adapter/adapter-common/src/main/java/org/dromara/dynamictp/adapter/common/DtpAdapterListener.java" \\
  && ok "adapter/adapter-common/src/main/java/org/dromara/dynamictp/adapter/common/DtpAdapterListener.java" \\
  || miss "missing critical file: adapter/adapter-common/src/main/java/org/dromara/dynamictp/adapter/common/DtpAdapterListener.java"
test -f "adapter/adapter-dubbo/src/main/java/org/dromara/dynamictp/adapter/dubbo/apache/DubboVersion.java" \\
  && ok "adapter/adapter-dubbo/src/main/java/org/dromara/dynamictp/adapter/dubbo/apache/DubboVersion.java" \\
  || miss "missing critical file: adapter/adapter-dubbo/src/main/java/org/dromara/dynamictp/adapter/dubbo/apache/DubboVersion.java"

# 5. Repo recency
days_since_last=$(( ( $(date +%s) - $(git log -1 --format=%at 2>/dev/null || echo 0) ) / 86400 ))
if [ "$days_since_last" -le 38 ]; then
  ok "last commit was $days_since_last days ago (artifact saw ~8d)"
else
  miss "last commit was $days_since_last days ago — artifact may be stale"
fi

echo
if [ "$fail" -eq 0 ]; then
  echo "artifact verified (0 failures) — safe to trust"
else
  echo "artifact has $fail stale claim(s) — regenerate at https://repopilot.app/r/dromara/dynamic-tp"
  exit 1
fi

Each check prints ok: or FAIL:. The script exits non-zero if anything failed, so it composes cleanly into agent loops (./verify.sh || regenerate-and-retry).

DynamicTp is a lightweight Java framework that makes ThreadPoolExecutor parameters dynamically configurable via distributed config centers (Nacos, Apollo, Zookeeper, Consul, Etcd) without code changes. It includes built-in metrics monitoring, alerting rules, and adapters to manage thread pools in third-party middleware like Dubbo, gRPC (Starlight), and brpc. Monorepo with modular structure: adapter/adapter-common/ provides abstract DtpAdapter base classes; specific adapters live in adapter/adapter-dubbo/, adapter/adapter-brpc/, adapter/adapter-grpc/, etc. Core thread pool management logic is in the main module (not shown in file list but referenced by adapters). JVMTI runtime support via separate modules for native bytecode instrumentation.

Java backend engineers building microservices who need to tune thread pool parameters (core/max pool size, queue depth, rejection policies) at runtime without redeploying, and operations teams who want real-time visibility into thread pool health and performance.

Production-ready. Active development with v1.2.2 as the latest stable release. Project shows GitHub/Gitee stars, CI/CD pipelines in .github/workflows/ (maven-build.yml, build-jvmti.yml), comprehensive test suites, and ongoing adapter integrations. Last visible structure suggests active maintenance.

Low-to-moderate risk. Dependencies on distributed config centers (Nacos, Apollo, etc.) introduce external operational complexity; misconfiguration can cascade to all consuming services. Single Java ecosystem focus. SPI-based extension model is well-designed but requires testing of custom adapters. No obvious single-maintainer bottleneck visible in structure.

Active expansion of adapter coverage—recent additions include Starlight (brpc) client/server adapters (adapter/adapter-brpc/src/main/java/org/dromara/dynamictp/adapter/brpc/), Dubbo adapters for both Alibaba and Apache versions. CI workflows validate Maven builds and JVMTI compilation. Focus appears to be on reducing code invasiveness and expanding middleware integration.

git clone https://github.com/dromara/dynamic-tp.git
cd dynamic-tp
mvn clean install -DskipTests
mvn spring-boot:run -pl dynamic-tp-example  # (if example module exists)

Daily commands: Project is a framework library, not a standalone service. To use: 1) Add dependency to your Spring Boot project: <dependency><groupId>org.dromara.dynamictp</groupId><artifactId>dynamic-tp-spring-boot-starter</artifactId><version>1.2.2</version></dependency>. 2) Configure thread pools in your config center (Nacos, Apollo, etc.). 3) Inject DynamicThreadPoolManager or use @DynamicTp annotation. 4) Start your application; thread pools load from config center on startup.

• adapter/adapter-common/src/main/java/org/dromara/dynamictp/adapter/common/DtpAdapter.java — Core interface defining the adapter contract that all middleware-specific thread pool adapters must implement
• adapter/adapter-common/src/main/java/org/dromara/dynamictp/adapter/common/AbstractDtpAdapter.java — Base abstract class providing common adapter functionality and lifecycle management for all concrete adapters
• adapter/adapter-dubbo/src/main/java/org/dromara/dynamictp/adapter/dubbo/apache/ApacheDubboDtpAdapter.java — Canonical example of a complete middleware adapter implementation showing pattern for managing external thread pools
• adapter/adapter-common/src/main/java/org/dromara/dynamictp/adapter/common/DtpAdapterListener.java — Event listener interface enabling reactive changes to thread pool configurations across all adapters
• adapter/adapter-dubbo/src/main/java/org/dromara/dynamictp/adapter/dubbo/apache/DubboVersion.java — Version detection utility showing how adapters handle multiple versions of the same middleware
• adapter/adapter-brpc/pom.xml — Module POM demonstrating dependency structure and parent-child relationship required for adapter modules
• adapter/adapter-motan/src/main/java/org/dromara/dynamictp/adapter/motan/StandardThreadExecutorProxy.java — Proxy pattern implementation showing how to wrap and dynamically control external middleware thread pools

Add a new middleware adapter

1. Create new module directory: adapter/adapter-{middleware}/ with subdirectories src/main/java/org/dromara/dynamictp/adapter/{middleware}/ (adapter/adapter-{middleware}/pom.xml)
2. Create concrete adapter class extending AbstractDtpAdapter implementing DtpAdapter interface (adapter/adapter-{middleware}/src/main/java/org/dromara/dynamictp/adapter/{middleware}/{MiddlewareName}DtpAdapter.java)
3. Implement init() to discover and register the middleware's thread pool instances (adapter/adapter-{middleware}/src/main/java/org/dromara/dynamictp/adapter/{middleware}/{MiddlewareName}DtpAdapter.java)
4. Implement update() method to dynamically modify thread pool parameters (coreSize, maxSize, queueCapacity, etc.) (adapter/adapter-{middleware}/src/main/java/org/dromara/dynamictp/adapter/{middleware}/{MiddlewareName}DtpAdapter.java)
5. If needed, create proxy wrapper class to intercept thread pool configuration calls (see StandardThreadExecutorProxy pattern) (adapter/adapter-{middleware}/src/main/java/org/dromara/dynamictp/adapter/{middleware}/{MiddlewareName}ThreadExecutorProxy.java)
6. Add pom.xml dependency on dynamic-tp-adapter-common and middleware-specific libraries (adapter/adapter-{middleware}/pom.xml)
7. Register adapter via SPI by creating META-INF/services/org.dromara.dynamictp.adapter.common.DtpAdapter file containing fully qualified class name (adapter/adapter-{middleware}/src/main/resources/META-INF/services/org.dromara.dynamictp.adapter.common.DtpAdapter)

Handle multiple versions of a middleware

1. Create version detection utility (see DubboVersion pattern) that identifies runtime version using reflection/classpath checks (adapter/adapter-{middleware}/src/main/java/org/dromara/dynamictp/adapter/{middleware}/{Middleware}Version.java)
2. Create separate adapter implementations for each major version (e.g., ApacheDubboDtpAdapter vs AlibabaDubboDtpAdapter) (adapter/adapter-{middleware}/src/main/java/org/dromara/dynamictp/adapter/{middleware}/v1/{Middleware}V1DtpAdapter.java)
3. In main adapter init() method, use version detector to instantiate and delegate to correct version-specific adapter (adapter/adapter-{middleware}/src/main/java/org/dromara/dynamictp/adapter/{middleware}/{Middleware}DtpAdapter.java)
4. Register only the main adapter via SPI, version-specific adapters are instantiated internally (adapter/adapter-{middleware}/src/main/resources/META-INF/services/org.dromara.dynamictp.adapter.common.DtpAdapter)

Add dynamic configuration change notification

1. In adapter class, implement DtpAdapterListener listener interface or instantiate listener anonymously (adapter/adapter-{middleware}/src/main/java/org/dromara/dynamictp/adapter/{middleware}/{MiddlewareName}DtpAdapter.java)
2. In update() method, call listener's onExecutorUpdated() method passing old and new configuration (adapter/adapter-{middleware}/src/main/java/org/dromara/dynamictp/adapter/{middleware}/{MiddlewareName}DtpAdapter.java)
3. Register listener with a central listener registry (framework provides this) in adapter init() method (adapter/adapter-{middleware}/src/main/java/org/dromara/dynamictp/adapter/{middleware}/{MiddlewareName}DtpAdapter.java)

• SPI (Service Provider Interface) — Enables dynamic discovery and loading of adapter implementations

1. Config center connectivity: Application will not start if configured config center (Nacos, Apollo, etc.) is unreachable at startup—requires operational setup before deployment. 2. SPI discovery: Custom adapters must be registered via META-INF/services/org.dromara.dynamictp.adapter.spi.DtpAdapter for auto-discovery; missing this silently fails to load adapters. 3. Thread safety in dynamic updates: Changing pool sizes, queue handlers on live pools requires understanding ThreadPoolExecutor's locking semantics—mistakes can cause deadlocks or task rejection. 4. JVMTI module: Native bytecode instrumentation (build-jvmti.yml) requires C++ compiler and JDK source; build failures here don't block pure Java adapters but limit certain monitoring features.

• Dynamic ThreadPool Reconfiguration — Core to DynamicTp: changing core/max pool size, queue depth, and rejection policies on live ThreadPoolExecutor instances requires understanding which methods are safe to call during execution without data loss or deadlock
• Service Provider Interface (SPI) — DynamicTp uses Java SPI (META-INF/services/) to auto-discover and load adapter implementations at runtime; critical for understanding how custom adapters and config centers are plugged in
• Distributed Configuration Management — The entire value prop of DynamicTp relies on pushing config changes from centralized stores (Nacos, Apollo, Consul, Etcd) to running JVM instances; understanding consistency, eventual consistency, and fallback strategies is essential
• Blocking Queue Backpressure & Rejection Policies — ThreadPoolExecutor uses rejection policies (Abort, Discard, CallerRuns, DiscardOldest) when queue is full; DynamicTp allows changing these dynamically, and incorrect changes can silently drop tasks
• JVMTI (JVM Tool Interface) — DynamicTp includes JVMTI-based bytecode instrumentation (build-jvmti.yml) for native-level thread pool interception in frameworks that bypass standard Java APIs; understanding this enables advanced monitoring
• Observability: Metrics, Logs, and Traces — DynamicTp's monitoring and alerting feature requires collecting ThreadPoolExecutor metrics (active threads, queue size, rejection count) and correlating with config changes; understanding instrumentation patterns is key
• Adapter Pattern for Middleware Integration — DynamicTp wraps third-party RPC frameworks (Dubbo, gRPC, brpc) whose thread pools don't natively support dynamic config; the adapter pattern isolates framework-specific code and allows uniform config management

• apache/dubbo — Dubbo is the primary RPC framework DynamicTp integrates with; understanding Dubbo's thread pool architecture helps when implementing or debugging the adapter
• alibaba/nacos — Nacos is the recommended config center for DynamicTp; many deployments use this for pushing thread pool config updates
• ctripcorp/apollo — Apollo is an alternative config center supported by DynamicTp; organizations using Apollo instead of Nacos rely on its SPI adapter implementation
• spring-cloud/spring-cloud-commons — DynamicTp integrates as a Spring Boot auto-configuration component; understanding Spring's ConfigService abstraction helps extend config center support
• alibaba/canal — Similar microservice governance pattern: Canal manages data pipeline state dynamically; DynamicTp applies the same config-center-driven architecture to thread pools

To work on one of these in Claude Code or Cursor, paste: Implement the "<title>" PR idea from CLAUDE.md, working through the checklist as the task list.

Add comprehensive unit tests for adapter pattern implementations

The adapter modules (adapter-dubbo, adapter-grpc, adapter-hystrix, adapter-brpc) lack visible test coverage. Given the critical nature of adapting third-party middleware thread pools, adding unit tests would ensure reliability across different RPC frameworks. This is especially important since AbstractDtpAdapter.java is the core abstraction that all adapters inherit from.

• [ ] Create adapter/adapter-dubbo/src/test/java/org/dromara/dynamictp/adapter/dubbo/ with tests for AlibabaDubboDtpAdapter and ApacheDubboDtpAdapter
• [ ] Create adapter/adapter-grpc/src/test/java/org/dromara/dynamictp/adapter/grpc/ with GrpcDtpAdapter unit tests
• [ ] Create adapter/adapter-brpc/src/test/java/org/dromara/dynamictp/adapter/brpc/ with StarlightClientDtpAdapter and StarlightServerDtpAdapter tests
• [ ] Add mock tests for DtpAdapterListener.java to verify callback behavior during thread pool updates

Implement SPI documentation and example provider in adapter-common

The README mentions 'can be customized through SPI' but there's no visible SPI implementation example or documentation. Adding a concrete SPI example module would help contributors understand how to extend the framework for new middleware. This should include META-INF/services configuration examples.

• [ ] Create adapter/adapter-common/src/main/resources/META-INF/services/org.dromara.dynamictp.adapter.common.DtpAdapter with example service provider interface declaration
• [ ] Add adapter/adapter-common/README.md documenting the SPI extension pattern with a minimal example implementation
• [ ] Create adapter/adapter-common/src/test/java/org/dromara/dynamictp/adapter/common/CustomAdapterSpiTest.java demonstrating how to implement a custom adapter

Add integration tests for DubboVersion compatibility and EagerThreadPoolExecutorProxy behavior

The adapter-dubbo module contains DubboVersion.java and EagerThreadPoolExecutorProxy.java which suggest complex version compatibility logic. These require integration tests to verify behavior across different Dubbo versions (Alibaba vs Apache), as breaking changes between versions could silently fail.

• [ ] Create adapter/adapter-dubbo/src/test/java/org/dromara/dynamictp/adapter/dubbo/DubboVersionCompatibilityTest.java to test version detection logic
• [ ] Create adapter/adapter-dubbo/src/test/java/org/dromara/dynamictp/adapter/dubbo/apache/EagerThreadPoolExecutorProxyTest.java to verify proxy behavior with mock ThreadPoolExecutor
• [ ] Add parameterized tests covering both Alibaba and Apache Dubbo scenarios in ApacheDubboDtpAdapter and AlibabaDubboDtpAdapter test classes

• Add integration tests for config center failover scenarios (e.g., verify thread pool params revert gracefully if Nacos becomes unreachable after initial load)—test files would live in adapter/*/src/test/
• Document the SPI extension pattern with a worked example: create a template adapter module adapter/adapter-template/ with inline JavaDoc showing how to wrap a custom thread pool and wire it via ServiceLoader
• Implement missing adapters for popular frameworks: add adapter/adapter-httpcomponents/ to manage Apache HttpClient thread pools, or adapter/adapter-vertx/ for Vert.x worker thread pools—follow ApacheDubboDtpAdapter.java structure

The dynamic-tp codebase demonstrates a reasonable security posture for a configuration-driven thread pool management library. The main concerns are: (1) integration with multiple external configuration centers without clear encryption/authentication details visible, (2) potential reflection-based security risks in the adapter pattern for third-party framework integration, and (3) supply chain risks from external dependencies like starlight-all. The architecture follows the SPI pattern which is good for extensibility but requires careful validation of dynamically loaded components. No hardcoded credentials or obvious injection vulnerabilities are evident in the provided file structure. Recommended actions include implementing comprehensive dependency scanning, enforcing secure configuration center communication, and auditing all reflection-based code paths for validation gaps.

• Medium · Optional Dependency on External BRPC Library — adapter/adapter-brpc/pom.xml. The dependency 'com.baidu.cloud:starlight-all' is marked as optional=true. While this reduces the attack surface for projects not using BRPC, it creates a supply chain risk if this dependency is compromised. The library comes from an external source (Baidu Cloud) and should be regularly audited for vulnerabilities. Fix: Regularly audit the starlight-all dependency for CVEs. Consider pinning to specific known-good versions and implementing dependency scanning in CI/CD pipeline using tools like OWASP Dependency-Check or Snyk.
• Medium · Potential Unsafe Reflection in Dynamic ThreadPool Adapters — adapter/ (all adapter modules). The adapter pattern with multiple third-party integrations (Dubbo, gRPC, Hystrix, Motan, LiteFlow) suggests dynamic class loading and reflection. This is common in SPI-based plugin systems and could lead to unsafe instantiation or method invocation if input validation is insufficient. Fix: Implement strict input validation and whitelist allowed adapter implementations. Use SecurityManager restrictions if running in a restricted environment. Audit all SPI implementations for reflective access patterns and ensure proper access controls.
• Medium · Configuration Center Integration Security — Core configuration management (specific files not shown in structure). The project integrates with multiple configuration centers (Nacos, Apollo, Zookeeper, Consul, Etcd). Dynamic configuration updates to thread pool settings could be exploited if the configuration center communication is not properly secured (e.g., no TLS, missing authentication, or unencrypted credentials). Fix: Enforce TLS/SSL for all configuration center communications. Implement strong authentication and authorization. Validate all configuration updates before applying them. Log all configuration changes for audit purposes. Encrypt sensitive configuration values at rest and in transit.
• Low · Missing Dependency Version Management — adapter/adapter-brpc/pom.xml and other pom.xml files. The pom.xml files use ${revision} for versioning and inherit from a parent pom. While this is a standard Maven pattern, it can obscure actual dependency versions if the parent pom or property definitions are not carefully controlled. Fix: Maintain a comprehensive dependency version matrix in the parent pom. Use Maven dependency management with explicit version ranges. Regularly run dependency:analyze to detect unused or conflicting dependencies. Implement a dependency update policy.
• Low · Monitoring and Alerting Information Disclosure — Core monitoring module (not shown in file structure). The project includes built-in monitoring and alerting functionality. If not properly configured, this could expose sensitive operational metrics or trigger alerts based on patterns that reveal system internals. Fix: Implement proper access control on monitoring endpoints. Filter sensitive metrics before exposure. Use secure channels for alert notifications. Implement rate limiting on metrics endpoints to prevent information leakage through timing attacks.

LLM-derived; treat as a starting point, not a security audit.

• Open issues — current backlog
• Recent PRs — what's actively shipping
• Source on GitHub

Generated by RepoPilot. Verdict based on maintenance signals — see the live page for receipts. Re-run on a new commit to refresh.