Skip to content

Feature request: Priming for powertools-idempotency #1997

Description

@phipag

Use case

PLEASE READ: Priming documentation: https://github.com/aws-powertools/powertools-lambda-java/blob/main/Priming.md

Parent issue: #1588
Sample PR: #1861

Java CRaC can be used to prime an application by implementing beforeCheckpoint() and afterRestore() hooks in selected classes. When used with AWS Snapstart, the beforeCheckpoint() hook runs before the memory snapshot is taken. This behavior can be leveraged to further reduce restore durations by pre-loading classes and calling commonly used code to incorporate this into the memory snapshot.

  1. Class-preloading / automatic priming: Based on a statically generated classesloaded.txt file, loads classes used at runtime into memory
  2. Invoke priming: Execute commonly used code e.g. to initialize all reflectively access objects, warm up caches, TCP connection pools etc. Common examples include performing "dry" AWS SDK calls (not impacting production resources) or performing JSON serialization/deserialization.

The goal of this issue is to implementing priming techniques for the powertools-idempotency module.

Solution/User Experience

Implement priming based on Priming Documentation (feel free to update documentation and suggest improvements):

Alternative solutions

Acknowledgment

Future readers

Please react with 👍 and your use case to help us understand customer demand.

Activity

  1. moved this from Triage to Backlog in Powertools for AWS Lambda (Java)on Aug 4, 2025
  2. dcabib commented on Jan 31, 2026

    @dcabib

    Hey @phipag!

    I've been looking into this issue and went through the PR #1861 to understand how the priming was implemented. Here's what I found and my plan to tackle this:

    Current State

    From what I can see, PR #1861 already implemented:

    • Automatic priming for powertools-metrics (the full class preloading flow)
    • Invoke priming for powertools-idempotency-dynamodb (warm-up calls to DynamoDB)

    The infrastructure is solid - ClassPreLoader in powertools-common is reusable and the pattern in MetricsFactory is pretty clean.

    What's Missing

    For powertools-idempotency-core, we still need the automatic priming (class preloading). The invoke priming checkbox is marked as done, so I'm assuming we only need the automatic part here.

    Implementation Plan

    Following the same pattern from MetricsFactory, here's what I'm thinking:

    1. Add CRaC dependency to powertools-idempotency-core/pom.xml

      <dependency>
          <groupId>org.crac</groupId>
          <artifactId>crac</artifactId>
      </dependency>
    2. Add Maven profile for class loading generation

      <profile>
          <id>generate-classesloaded-file</id>
          <!-- same pattern as metrics module -->
      </profile>
    3. Modify Idempotency.java to implement Resource:

      • Add static INSTANCE field
      • Register with Core.getGlobalContext().register(INSTANCE) in static block
      • Implement beforeCheckpoint() → call getInstance() + ClassPreLoader.preloadClasses()
      • Implement empty afterRestore()
    4. Generate and cleanup classesloaded.txt:

      • Run mvn -Pgenerate-classesloaded-file clean test
      • Clean up with the regex patterns from Priming.md
      • Place in src/main/resources/classesloaded.txt

    Questions

    • Does this approach sound right, or am I missing something?
    • The Idempotency class uses the holder pattern for singleton - should I create the static instance for CRaC registration similarly to how it was done in MetricsFactory?
    • Any specific test scenarios you'd like me to cover?

    Let me know if this looks good and if you need help implementing this! Happy to open a PR if you're cool with the approach.

  3. phipag commented on Feb 2, 2026

    @phipag
    ContributorAuthor

    Hey @dcabib,

    thanks for proposing to work on this. Feel free to give this a go. The high-level plan sounds about right. You can follow the similar approach like in the MetricsFactory case and these two other PRs:

    Regarding testing: If you can, it would be great if you can test to deploy an example Lambda in your AWS account and double-check if the snapstart hooks run. For example, you can print a line from the hooks and verify in cloudwatch logs that it exists for a snapstart enabled lambda function.

  4. phipag commented on Feb 2, 2026

    @phipag
    ContributorAuthor

    I assigned this issue to you. Let me know if new questions come up in the meantime.

  5. dcabib commented on Feb 2, 2026

    @dcabib

    Hey @phipag,

    I've completed the automatic priming implementation for powertools-idempotency and wanted to clarify the scope before opening a PR.

    What I Implemented

    I implemented automatic priming in powertools-idempotency-dynamodb (specifically in DynamoDBPersistenceStore.java), following the pattern from PR #2145 (Kafka) and PR #2345 (Tracing):

    Changes:

    • ✅ Added powertools-common dependency to powertools-idempotency-dynamodb/pom.xml
    • ✅ Added Maven profile generate-classesloaded-file
    • ✅ Modified DynamoDBPersistenceStore.java to call ClassPreLoader.preloadClasses() in existing beforeCheckpoint() hook
    • ✅ Generated classesloaded.txt (8,726 classes including 47 from idempotency-core)
    • ✅ Added unit tests for CRaC hooks

    Potential Discrepancy

    In my initial comment on this issue, I proposed implementing automatic priming in powertools-idempotency-core (modifying Idempotency.java), similar to how MetricsFactory works in the metrics module.

    However, looking at the reference PRs you mentioned:

    The idempotency module is different - it has two sub-modules:

    • powertools-idempotency-core (interfaces, base classes)
    • powertools-idempotency-dynamodb (concrete DynamoDB implementation)

    Question

    Should automatic priming be implemented in:

    Option 1: Only in powertools-idempotency-dynamodb (what I implemented)

    Option 2: Also in powertools-idempotency-core (my initial proposal)

    • ✅ Would follow the singleton pattern like MetricsFactory
    • ✅ More modular (core independent of specific implementation)
    • ✅ Future-proof if other persistence implementations are added
    • ❌ Potential duplication since dynamodb module already loads core classes

    Which approach aligns with your vision for the module architecture?

    Thanks for the guidance!

  6. phipag commented on Feb 2, 2026

    @phipag
    ContributorAuthor

    Hey @dcabib, Option 1 sounds good. Only add it in -dynamodb for now.

  7. added a commit that references this issue on Feb 2, 2026
    1df82c3
  8. dcabib commented on Feb 2, 2026

    @dcabib

    Hey @phipag!

    Just opened PR #2376 with the automatic priming implementation for idempotency-dynamodb. Followed your guidance to go with Option 1 (only in -dynamodb module).

    Ready for review when you get a chance!

    Cheers

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

Type

No type

Projects

Milestone

No milestone

Relationships

None yet

Development

No branches or pull requests

Issue actions